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ПРЕДИСЛОВИЕ ОТ АВТОРА, 
или ЗАЧЕМ НУЖНА ЭТА КНИГА 


Выражаю огромную благодарность коллегам из 
ЕРАМ Software Testing Division за ценные замечания 
и рекомендации в процессе подготовки материала. 


Особую благодарность выражаю тем сотням 
читателей, которые присылали вопросы, пожелания, 
замечания — благодаря вашему вкладу книга стала лучше. 


В основу этой книги положен десятилетний опыт проведения тренингов для начинающих 
тестировщиков. За это время накопилась огромная коллекция вопросов от слушателей, и стали 
отчётливо видны типичные для многих начинающих проблемы и сложности. Представляется 
разумным обобщить этот материал в виде книги, которая поможет начинающим тестировщикам 
быстрее погрузиться в профессию и избежать многих досадных ошибок. 


С момента выхода первого издания в книгу было внесено множество правок, основанных на 
отзывах читателей и переосмыслении автором отдельных идей и формулировок. Благодаря во- 
просам читателей и дискуссиям на тренингах удалось уточнить и сгладить спорные моменты, 
прояснить определения и дать пояснения там, где это оказалось необходимым. Идеал недости- 
жим, но хочется верить, что в его направлении был сделан большой шаг. 


Эта книга не ставит своей задачей полноценное раскрытие всей предметной области со всеми 
её нюансами, потому не воспринимайте её как учебник или справочник — за десятилетия раз- 
вития тестирование накопило такой объём данных, что для его формального представления не 
хватит и десятка книг. Также прочтения лишь этой одной книги вовсе не достаточно, чтобы стать 
«гуру тестирования». 

Тогда зачем же нужна эта книга!? 

Во-первых, эту книгу стоит прочитать, если вы твёрдо решили заниматься тестированием, — 
она будет полезна как «совсем начинающим», так и имеющим некоторый опыт в тестировании. 

Во-вторых, эту книгу можно и нужно использовать как опорный материал во время тренин- 
гов. Здесь можно и нужно много чёркать, дописывать, отмечать непонятное, записывать вопро- 
сы ит.д. 

В-третьих, эта книга — своего рода «карта», в которой есть ссылки на множество внешних 
источников информации (которые могут оказаться полезными даже опытным тестировщикам), 
а также много примеров с пояснениями. 
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Прежде чем мы приступим к изучению основного материала, давайте определимся с условны- 
ми обозначениями: 


Определения и иная важная для запоминания информация. Часто будет встречаться 
рядом со следующим знаком. 


Дополнительные сведения или отсылка к соответствующим источникам. Всё то, что 
полезно знать. При этом оригинальные (англоязычные) определения будут приведены 
в сносках. 


Предостережения и частые ошибки. Недостаточно показать, «как правильно», часто 
большую пользу приносят примеры того, как поступать не стоит. 


Задания для самостоятельной проработки. Настоятельно рекомендуется выполнять их 
(даже если вам кажется, что всё очень просто). 


В приложении!283} есть комментарии ко многим заданиям, но не спешите туда загляды- 
вать — сначала поработайте самостоятельно. 


В тексте вы встретите два вида сносок в виде чисел: если число не взято в фигурные скоб- 
ки!2345 — это обычная сноска, которую нужно искать внизу страницы; если число взято в фигур- 
ные скобки 2345} — оно представляет собой номер страницы, где представлены дополнительные 
сведения (в электронной версии книги такая сноска является ссылкой). 


Напоследок: ничто в этой книге не является догмой, к любому термину вы можете найти аль- 
тернативное определение, к любой рекомендации — контраргументы. И это нормально. Со вре- 
менем вы станете понимать контекст ситуации и применимость (полезность!) той или иной ин- 
формации. Итак, приступим! 


ТЕСТИРОВАНИЕ 
И ТЕСТИРОВЩИКИ 


РАЗДЕЛ 


ЧТО ТАКОЕ ТЕСТИРОВАНИЕ 
И ОТКУДА ОНО ПОЯВИЛОСЬ 


В первую очередь дадим определение тестирования ПО, чтобы чётче понимать, о чём пой- 
дёт речь. 


Тестирование программного обеспечения — процесс анализа программного средства 
и сопутствующей документации с целью выявления дефектов и повышения качества 
продукта. 


В глоссарии ISTQB! нет термина «тестирование ПО», который широко используется в 
русском языке. Там есть лишь термин «тестирование (testing?)». 


На протяжении десятилетий развития разработки ПО к вопросам тестирования и обеспече- 
ния качества подходили очень и очень по-разному. Можно выделить несколько основных «эпох 
тестирования». 


В 50-60-х годах прошлого века процесс тестирования был предельно формализован, отделён 
от процесса непосредственной разработки ПО и «математизирован». Фактически тестирование 
представляло собой скорее отладку программ (debugging?). Существовала концепция т.н. «ис- 
черпывающего тестирования (exhaustive testingt)» — проверки всех возможных путей выполне- 
ния кода со всеми возможными входными данными. Но очень скоро было выяснено, что исчер- 
пывающее тестирование невозможно, т.к. количество возможных путей и входных данных очень 
велико, а также при таком подходе сложно найти проблемы в документации. 


І International Software Testing Qualifications Board Glossary. [http://www.istqb.org/downloads/glossary.html] 

2 Testing. The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, prepa-ration 
and evaluation of software products and related work products to determine that they satisfy specified re-quirements, to 
demonstrate that they are fit for purpose and to detect defects. [ISTQB Glossary] 


3 Debugging. The process of finding, analyzing and removing the causes of failures in software. [ISTQB Glossary] 
4 Complete testing, exhaustive testing. A test approach in which the test suite comprises all combinations of input values 
and preconditions. [ISTQB Glossary] 
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определяет, может ли существовать треугольник с такими длинами сторон. Допустим, 
что ваша программа выполняется в некоей изолированной идеальной среде, и вам все- 
го-то осталось проверить корректность её работы на трёх 8-байтовых знаковых целых 
числах. Вы используете автоматизацию, и компьютер может провести 100 миллионов 
проверок в секунду. Сколько займёт проверка всех вариантов? 


© Задание 1.1.а: представьте, что ваша программа по трём введённым целым числам 


А задумались ли вы, как подготовить для этого теста проверочные данные (на OCHO- 
Be KOTOPÞIX МОЖНО определить, верно ли сработала программа в каждом конкретном 
случае)? 


В 70-х годах фактически родились две фундаментальные идеи тестирования: тестирование 
сначала рассматривалось как процесс доказательства работоспособности программы в некото- 
рых заданных условиях (positive testing”), азатем — строго наоборот: как процесс доказательства 
неработоспособности программы в некоторых заданных условиях (negative testingć). Это BHY- 
треннее противоречие не только не исчезло со временем, но и в наши дни многими авторами 
совершенно справедливо отмечается как две взаимодополняющие цели тестирования. 

Отметим, что «процесс доказательства неработоспособности программы» ценится чуть боль- 
ше, т.к. не позволяет закрывать глаза на обнаруженные проблемы. 


Внимание! Скорее всего, именно из этих рассуждений проистекает неверное пони- 
мание того, что негативные тест-кейсы должны заканчиваться возникновением сбоев 
и отказов в приложении. Нет, это не так. Негативные тест-кейсы пытаются вызвать 
сбои и отказы, но корректно работающее приложение выдерживает это испытание и 
продолжает работать верно. Также отметим, что ожидаемым результатом негативных 
тест-кейсов является именно корректное поведение приложения, а сами негативные 
тест-кейсы считаются пройденными успешно, если им не удалось «поломать» приложе- 
ние. (См. подробности в главе «Чек-листы, тест-кейсы, наборы тест-кейсов»!117)). 


Много «классики тестирования» можно почерпнуть из книги «Искусство тестирова- 
ния программ» Гленфорда Майерса (издания 1979, 2004, 2011 годов). Однако большин- 
ство критиков отмечает, что эта книга мало подходит для начинающих и куда больше 
ориентирована на программистов, чем на тестировщиков. Что, впрочем, не умаляет её 
ценности. В оригинале книга называется «Те art of software testing» (Glenford J. Myers). 


Итак, ещё раз самое важное, что тестирование «приобрело» в 70-е годы: 

e тестирование позволяет удостовериться, что программа соответствует требованиям; 

• тестирование позволяет определить условия, при которых программа ведёт себя некоррек- 
тно. 


В 80-х годах произошло ключевое изменение места тестирования в разработке ПО: вместо 
одной из финальных стадий создания проекта тестирование стало применяться на протяжении 
всего цикла разработки (software lifecycle”) (также см. описание итерационной инкрементальной 
модели разработки ПО в главе «Модели разработки ПО»{20}), что позволило в очень многих слу- 
чаях не только быстро обнаруживать и устранять проблемы, но даже предсказывать и предот- 
вращать их появление. 


5 Positive Testing. Testing aimed at showing software works. Also known as «test to pass». [aptest.com] 

6 Negative testing. Testing aimed at showing software does not work. Also known as «test to fail». [aptest.com] 

7 Software lifecycle. The period of time that begins when a software product is conceived and ends when the software 
is no longer available for use. The software lifecycle typically includes a concept phase, requirements phase, design phase, 
implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement 
phase. Note these phases may overlap or be performed iteratively. [ISTQB Glossary] 
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В этот же период времени отмечено бурное развитие и формализация методологий тестирова- 
ния и появление первых элементарных попыток автоматизировать тестирование. 


В 90-х годах произошёл переход от тестирования как такового к более всеобъемлющему про- 
цессу, который называется «обеспечение качества (quality assurances)», охватывает весь цикл 
разработки ПО и затрагивает процессы планирования, проектирования, создания и выполнения 
тест-кейсов, поддержку имеющихся тест-кейсов и тестовых окружений. Тестирование вышло на 
качественно новый уровень, который естественным образом привёл к дальнейшему развитию 
методологий, появлению достаточно мощных инструментов управления процессом тестирова- 
ния и инструментальных средств автоматизации тестирования, уже вполне похожих на своих 
нынешних потомков. 


Хорошим источником дополнительной информации о процессах тестирования явля- 
ется книга Рекса Блэка «Ключевые процессы тестирования» («Critical Testing Processes», 
Rex Black). 


В нулевые годы нынешнего века развитие тестирования продолжалось в контексте поиска 
всё новых и новых путей, методологий, техник и подходов к обеспечению качества. Серьёзное 
влияние на понимание тестирования оказало появление гибких методологий разработки и таких 
подходов, как «разработка под управлением тестированием? (test-driven development!?, TDD)». 
Автоматизация тестирования уже воспринималась как обычная неотъемлемая часть большин- 
ства проектов, а также стали популярны идеи о том, что во главу процесса тестирования следу- 
ет ставить не соответствие программы требованиям, а её способность предоставить конечному 
пользователю возможность эффективно решать свои задачи. 


О современном этапе развития тестирования мы будем говорить на протяжении всего осталь- 
ного материала. Если же отметить вкратце основные характеристики, то получится примерно 
такой список: гибкие методологии и гибкое тестирование, глубокая интеграция с процессом 
разработки, широкое использование автоматизации, колоссальный набор технологий и инстру- 
ментальных средств, кроссфункциональность команды (когда тестировщик и программист во 
многом могут выполнять работу друг друга). 


Воистину подробнейшую историю развития тестирования ПО (начиная с 1822 года, 
не шутка) можно найти в статье «The History of Software Testing»!! на ресурсе «Testing 
References». Также немалый интерес представляет статья «Ihe Growth of Software 
Testing»!? (Рама Gelperin, Bill Hetzel). 


© Задание 1.1.Ъ: если вам не очень хорошо знакомы такие понятия как TDD, BDD, DDT, 


© 


КРОТ, — найдите их описание в Интернете и изучите. Конечно же, это задание относит- 
ся и клюбым другим непонятным терминам. 


8 Quality assurance. Part of quality management focused оп providing confidence that quality requirements will be ful- 
filled. [ISTQB Glossary] 

7 Да, грамматически корректно будет «разработка под управлением тестирования», но традиционно так сло- 
жилось, что целый ряд подобных подходов «под управлением...» называют, используя творительный падеж: 
т.е. «...тестированием», «...данными», «...ключевыми словами» и т.д. 

10 Test-driven development. А way of developing software where the test cases аге developed, and often automated, before 
the software is developed to run those test cases. [ISTQB Glossary] 

11 «The History of Software Testing» [http://www.testingreferences.com/testinghistory.php] 

12 «The Growth of Software Testing», David Gelperin, Bill Hetzel [http://www.clearspecs.com/downloads/ClearSpecs16V01_ 
GrowthOfSoftwareTest.pdf] 
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КТО ТАКОЙ ТЕСТИРОВЩИК 
И ЧТО ОН ДЕЛАЕТ 


Если поискать информацию по ключевым фразам из названия этой главы, можно найти уйму 
совершенно противоречивых ответов. И дело здесь в первую очередь в том, что авторы большин- 
ства «должностных обязанностей» приписывают всей профессии некий утрированный набор 
характеристик отдельных её представителей. 

В то же время даже в ЕКСД разделены должности «специалиста по тестированию программ- 
ного обеспечения» и «тестировщика программного обеспечения». 


альной защиты Республики Беларусь № 148 от 15 декабря 2009 г. О внесении изменений 
и дополнений в выпуск 1 Единого квалификационного справочника должностей слу- 
жащих (ЕКСД)». 


© Если вам интересно, почитайте документ «Постановление Министерства труда и соци- 


Теперь вернёмся к исходному вопросу и посмотрим на него с двух точек зрения: какова квали- 
фикация тестировщика, и где он работает. 


Упрощённо отразим это в таблице 1.2.а. 


Таблица 1.2.а — Типичные виды деятельности тестировщика. 


Небольшие фирмы Большие фирмы 
Подмастерье, часто предостав- | Рядовой участник проектов, одно- 
Низкая квалификация |ленный сам себе в решении | временно проходящий интенсивное 
задач. повышение квалификации. 


Мастер на все руки с богатым, | Эксперт в одной или нескольких об- 
Высокая квалификация | но не всегда структурирован- | ластях, консультант, руководитель 
ным опытом. направления. 


Поскольку чем выше квалификация специалиста{?82}, тем шире его выбор мест работы (даже 
в рамках одной крупной фирмы), основное внимание уделим именно квалификационным OCO- 
бенностям работы тестировщика. 

В начале карьеры любой специалист (и тестировщик не является исключением) является ис- 
полнителем и учеником. Достаточно хорошо понимать, что такое тест-кейсы, отчёты о дефектах, 
уметь читать требования, пользоваться парой инструментальных средств и хорошо уживаться 
в команде. 

Постепенно тестировщик начинает погружаться во все стадии разработки проекта, понимая 
их всё полнее и полнее, начинает не только активно использовать, но и разрабатывать проектную 
документацию, принимать всё более ответственные решения. 

Если выразить образно главную цель тестировщика, то она будет звучать так: «понимать, что 
в настоящий момент необходимо проекту, получает ли проект это необходимое в должной мере, 
и если нет, как изменить ситуацию к лучшему». Звучит похоже на цель руководителя проекта, 
верно? Верно. Начиная с некоторого уровня развития, ІТ-специалисты, по большому счёту, pas- 
личаются лишь наборами технических навыков и основной областью приложения этих навыков. 


Так какие же технические навыки нужны, чтобы успешно начать работать тестировщиком? 
Прежде чем приступить к самому перечислению, оговорим особо: этот список рассчитан в пер- 
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вую очередь на тех, кто приходит в тестирование из нетехнических профессий (хотя часто его же 
приходится озвучивать и студентам технических вузов). 


0) Знание иностранных языков. Да, это нетехнический навык. Но тем не менее он идёт под 


Ө Задание 1.2.а: если вы сомневаетесь в том, достаточен ли ваш уровень английского, 


номером «ноль». Можете считать это аксиомой: «нет знания английского — нет карьеры 
в IT». Другие иностранные языки тоже приветствуются, но английский первичен. 


проверьте себя: если вы можете без труда читать технические статьи хотя бы в Википе- 
дии, минимально достаточный уровень у вас есть. 


1) Уверенное владение компьютером на уровне по-настоящему продвинутого пользователя и 


2) 


3) 


4) 


5) 


желание постоянно развиваться в этой области. Можете ли вы представить себе профес- 
сионального повара, который не может пожарить картошку (не «не обязан», а «не умеет в 
принципе»)? Выглядит странно? Не менее странно выглядит «ГГ’шник» (именно так, в Ka- 
вычках), неспособный набрать вменяемо отформатированный текст, скопировать файл по 
сети, развернуть виртуальную машину или выполнить любое иное повседневное рутинное 
действие. 

Программирование. Оно на порядки упрощает жизнь любому ГГ’шнику — и тестировщи- 
ку в первую очередь. Можно ли тестировать без знания программирования? Да, можно. 
Можно ли это делать по-настоящему хорошо? Нет. И сейчас самый главный (почти религи- 
озно-философский) вопрос: какой язык программирования изучать? С/С++/С#, Java, РНР, 
JavaScript, Python, Ruby и т.д. — начинайте с того, на чём написан ваш проект. Если проекта 
пока ещё нет, начинайте с JavaScript (на текущий момент — самое универсальное решение). 
Базы данных и язык 501. Здесь от тестировщика тоже не требуется квалификация на уров- 
не узких специалистов, но минимальные навыки работы с наиболее распространёнными 
СУБД и умение писать простые запросы можно считать обязательными. 

Понимание принципов работы сетей и операционных систем. Хотя бы на минимальном 
уровне, позволяющем провести диагностику проблемы и решить её своими силами, если 
это возможно. 

Понимание принципов работы веб-приложений и мобильных приложений. В наши дни 
почти всё пишется именно в виде таких приложений, и понимание соответствующих тех- 
нологий становится обязательным для эффективного тестирования. 


Надеюсь, ВЫ обратили внимание на то, что самого тестирования в списке нет. Всё верно, ведь 
ему посвящена вся эта книга целиком, так что позволим себе не копировать её сюда. 


В завершение главы также отметим личностные качества, позволяющие тестировщику бы- 
стрее стать отличным специалистом: 


1) 
2) 


3) 
4) 
5) 


повышенная ответственность и исполнительность; 

хорошие коммуникативные навыки, способность ясно, быстро, чётко выражать свои 
мысли; 

терпение, усидчивость, внимательность к деталям, наблюдательность; 

хорошее абстрактное и аналитическое мышление; 

способность ставить нестандартные эксперименты, склонность к исследовательской дея- 
тельности. 


Да, сложно найти человека, который бы в равной мере обладал всеми перечисленными каче- 
ствами, но всегда полезно иметь некий ориентир для саморазвития. 


ническое высшее образование. Не обязательно. Хотя при его наличии на первых этапах 
карьеры, конечно, легче. Но со временем разница между теми, у кого такое образование 
есть, и теми, у кого нет, становится практически незаметной. 


© Очень часто можно услышать вопрос о том, обязательно ли тестировщику иметь тех- 
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И ЧЕМУ МОЖНО НАУЧИТЬСЯ 


В предыдущей главе мы осознанно не обсуждали конкретный перечень необходимых начи- 
нающему тестировщику знаний и умений, т.к. он заслуживает отдельного рассмотрения. 

Показанные ниже данные представляют собой адаптированную выжимку из карты компетен- 
ций тестировщика. Все навыки здесь условно разделены на три группы: 


» Профессиональные — это именно «тестировщицкие», ключевые навыки, отличающие тес- 
тировщика от других ІТ-специалистов. 

e Технические — это общие навыки в области ІТ, которыми тем не менее должен обладать и 
тестировщик. 

• Личностные — в русском языке термин «soft skills» часто переводят как «навыки межлич- 
ностного общения», но исходный термин несколько шире. 


непонятные вещи, ищите дополнительную информацию и добивайтесь у себя понима- 


Ө Задание 1.3.а: в процессе чтения приведённых здесь перечней компетенций отмечайте 
ния описанного хотя бы на уровне «знаю, о чём идёт речь». 


ПРОФЕССИОНАЛЬНЫЕ НАВЫКИ 


Таблица 1.3.а — Профессиональные навыки тестировщика 


Предметная Начальный Уровень младшего 
область уровень или среднего специалиста 
Процессы тестирования и разработки программного обеспечения 
ОВС Глубокое понимание стадий процесса тестирования, 
ЕС рования хону вопрову их взаимосвязи и взаимовлияния, умение планиро- 
ПО ке а вать собственную работу в рамках полученного зада- 
ния в зависимости от стадии тестирования 
«Процессы тестиро- т 
Процесс вания и разработки Общее понимание моделей разработки ПО, их связи 
роса ПО»(20} с тестированием, умение расставлять приоритеты в 
ПО собственной работе в зависимости от стадии разви- 
тия проекта 
Работа с документацией 
Умение определять взаимосвязи и взаимозависи- 
Анализ мость между различными уровнями и формами 
требований Этому вопросу |представления требований, умение формулировать 
посвящена глава | вопросы с целью уточнения неясных моментов 
«Тестирование |Знание свойств хороших требований и наборов тре- 
естара вие согоо бований, умение анализировать требования с целью 
требований итреоований» выявления их недостатков, умение устранять недо- 
статки в требованиях, умение применять техники 
повышения качества требований 
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Таблица 1.3.а [продолжение] 


Предметная Начальный Уровень младшего 
область уровень или среднего специалиста 
Управление Общее понимание процессов выявления, документи- 
требованиями рования, анализа и модификации требований 
Не требуется 


Бизнес-анализ 


Общее понимание процессов выявления и докумен- 
тирования различных уровней и форм представле- 
ния требований 


Оценка и планирование 


Создание плана 


Эти вопросы 


Общее понимание принципов планирования в кон- 
тексте тестирования, умение использовать готовый 


тестирования частично затрону- Н 
тест-план для планирования собственной работы 
ты в главе «Оценка 
трудозатрат, 
Создание Общее понимание принципов построения стратегии 
планирование 
стратегии g тестирования, умение использовать готовую страте- 
Р и отчётность»1206б}, Р ny ё а 5 
тестирования гию для планирования собственной работы 
но их глубокое 
понимание требует 
Общее понимание принципов оценки трудозатрат, 
Оценка отдельного длитель- 
умение оценивать собственные трудозатраты при 
трудозатрат ного изучения у 
планировании собственной работы 
Работа с тест-кейсами 
Твёрдое умение использовать техники и подходы K 
Создание проектированию тестовых испытаний, умение де- 


чек-листов 


Создание 
тест-кейсов 


Этому вопросу 
посвящена глава 
«Чек-листы, 


тест-кейсы, наборы 


тест-кейсов» 117} 


композировать тестируемые объекты и поставлен- 
ные задачи, умение создавать чек-листы 


Твёрдое умение оформлять тест-кейсы согласно при- 
нятым шаблонам, умение анализировать готовые 
тест-кейсы, обнаруживать и устранять имеющиеся B 
них недостатки 


Управление 
тест-кейсами 


Не требуется 


Общее понимание процессов создания, модифика- 
ции и повышения качества тест-кейсов 


Методологии тестирования 


Функциональное 
и доменное 
тестирование 


Этому вопросу 
посвящена глава 
«Подробная 
классификация 
тестирования» {68} 


Знание видов тестирования, твёрдое умение ис- 
пользовать техники и подходы к проектированию 
тестовых испытаний, умение создавать чек-листы и 
тест-кейсы, умение создавать отчёты о дефектах 
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Таблица 1.3.а [окончание] 
Предметная Начальный Уровень младшего 
область уровень или среднего специалиста 
Тестирование Умение проводить тестирование интерфейса пользо- 
интерфейса вателя на основе готовых тестовых сценариев или в 
пользователя рамках исследовательского тестирования 
Общее умение использовать матрицы для быстрого 
Исследовательское определения сценариев тестирования, общее умение 
тестирование проводить новые тесты на основе результатов только 
что выполненных 
Интеграционное Умение проводить интеграционное тестирование на 
тестирование Не требуется основе готовых тестовых сценариев 
Локализационное Умение проводить локализационное тестирование 
тестирование на основе готовых тестовых сценариев 
Инсталляционное Умение проводить инсталляционное тестирование 
тестирование на основе готовых тестовых сценариев 
Общее понимание принципов организации регрес- 
Регрессионное 
сионного тестирования, умение проводить регресси- 
тестирование 
онное тестирование по готовым планам 
Работа с отчётами о дефектах 
Твёрдое знание жизненного цикла отчёта об ошибке, 
Этому вопросу 


Создание отчётов 
о дефектах 


посвящена глава 
«Отчёты 
о дефектах» 167} 


твёрдое умение создавать отчёты о дефектах соглас- 
но принятым шаблонам, умение анализировать гото- 
вые отчёты, обнаруживать и устранять имеющиеся в 
них недостатки 


Анализ причин 
возникновения 
ошибки 


Использование 
баг-трекинговых 
систем 


Не требуется 


Базовое умение исследовать приложение с целью вы- 
явления источника (причины) ошибки, элементар- 
ное умение формировать рекомендации по устране- 
нию ошибки 


Умение использовать баг-трекинговые системы на 
всех стадиях жизненного цикла отчётов о дефектах 


Работа с отчётами о результатах тестирования 


Создание отчётов 
о результатах 
тестирования 


Не требуется, 
но частично 
рассмотрено 
в главе «Оценка 
трудозатрат, 
планирование 


и отчётность» 206} 


Умение предоставлять необходимую информацию 
для формирования отчёта о результатах тестирова- 
ния, умение анализировать готовые отчёты о резуль- 
татах тестирования с целью уточнения планирова- 
ния собственной работы 
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ТЕХНИЧЕСКИЕ НАВЫКИ 
Таблица 1.3.6 — Технические навыки тестировщика 
Предметная Начальный Уровень младшего 
область уровень или среднего специалиста 
Операционные системы 
Использование |Установка, использование и администрирование, pe- 
Windows на уровне уверен- |шение проблем, конфигурирование с целью настрой- 
ного пользователя |ки тестового окружения и выполнения тест-кейсов 
Установка, использование и администрирование, ре- 
Linux Общее знакомство | шение проблем, конфигурирование с целью настрой- 
ки тестового окружения и выполнения тест-кейсов 
Мас О$ Не требуется Общее знакомство 
ТЭНИН Использование | Установка, использование и администрирование, pe- 
с на уровне начинаю- | шение проблем, конфигурирование с целью настрой- 
щего пользователя | ки тестового окружения и выполнения тест-кейсов 
Базы данных 
Реляционная Общее понимание, умение читать и понимать схемы 
теория баз данных в общепринятых графических нотациях 
Умение устанавливать, настраивать и использовать 
Ляо ля настройки тестового окружения и выполнения 
СУБД Не требуется а TP PY 
тест-кейсов 
Умение писать и выполнять простые запросы с ис- 
Язык SQL пользованием инструментальных средств работы с 
БД/СУБД13 
Компьютерные сети 
бане Общее понимание принципов работы стека TCP/IP, 
умение конфигурировать локальные сетевые на- 
протоколы я ; 
Не требуется стройки операционной системы 
Общее понимание и умение использовать утилиты 
Сетевые утилиты 
диагностики состояния и неполадок в сети 
Веб-технологии 
Беб-серьери Общее понимание принципов работы веб-серверов, 
рвер умение устанавливать и настраивать 
Серверы Потреби Общее понимание принципов работы серверов при- 
приложений резу ложений, умение устанавливать и настраивать 
Веб-сервисы Общее понимание принципов работы веб-сервисов и 
P способов диагностики неполадок B их работе 
Общее 
a Умение использовать HTML и CSS для создания npo- 
Языки разметки представление | ану 
об НТМГ и С$$ р 


13 «Работа с MySQL, MS SQL Server и Oracle в примерах», Святослав Куликов [http://svyatoslav.biz/database_book/] 
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Таблица 1.3.6 [окончание] 
Предметная Начальный Уровень младшего 
область уровень или среднего специалиста 
Протоко Общее понимание принципов работы протоколов 
колы 
р прикладного уровня О$1-модели, общее понимание 
передачи данных 
принципов диагностики возникших неполадок 
Не требуется 
Языки Начальные знания хотя бы в одном языке програм- 
веб-программиро- мирования, используемом для создания веб-прило- 
вания жений 
Мобильные платформы и технологии 
: Использование на уровне начинающего пользова- 
Android УР |. 
теля 
Использование на уровне начинающего пользова- 
105 Не требуется УР Б 
теля 
; Использование на уровне начинающего пользова- 
Windows Phone УР а 
теля 
ЛИЧНОСТНЫЕ НАВЫКИ 
Таблица 1.3.с — Личностные навыки тестировщика 
Предметная Начальный Уровень младшего 
область уровень или среднего специалиста 
Коммуникативные навыки 
Понимание и строгое следование правилам делового 
Деловое использо- Минимальные } 
общения с использованием e-mail и сервисов мгно- 
вание e-mail навыки . 
венных сообщений 
Устное деловое Минимальные |Понимание и строгое следование правилам устного 
общение навыки делового общения 
Прохождение В Р 
> Не требуется Начальный опыт прохождения собеседований 
собеседований 
Навыки самоорганизации 
Минимальные |Развитые навыки планирования собственного вре- 
Планирование 
навыки, мени, умение пользоваться соответствующими ин- 
собственного 
ека общие представ- |струментами, умение оценивать трудозатраты в рам- 
Р ления ках полученных заданий 
Отчётность Развитые навыки отчётности о своей работе, умение 
К Начальные навыки 
о своей работе пользоваться соответствующими инструментами 


Возможно, вы заметили, что в этом перечне навыков нет отдельного списка, посвящённого 
автоматизации тестирования. Он не включён в данную книгу по трём причинам: а) он огромен; 
б) он постоянно меняется; в) эта книга всё же о тестировании вообще, хоть в ней и есть краткие 
сведения об автоматизации (см. раздел «Автоматизация тестирования»1?57}). Если же сказать в 
двух словах, то автоматизатор должен знать всё то же, что и «классический» тестировщик, а так- 
же уметь программировать на 3-5 языках — хотя бы немного. И всё. Инструменты на начальном 
уровне можно освоить за несколько дней. 
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МИФЫ И ЗАБЛУЖДЕНИЯ 
0 ТЕСТИРОВАНИИ 


Возможно, здесь вы ожидали прочитать нечто наподобие «Семи бед тестирования» Джеймса 
Виттакера (см. ниже). Нет, здесь будут «мифы», которые актуальны не для состоявшихся про- 
фессионалов, а для новичков и тех, кто ещё только собирается обучаться тестированию. 

Текст этой главы составлен в основном по итогам бесед со слушателями тренингов, а если точ- 
нее — по фразам, начинающимся с «а я думал(а), что...» или «а правда ли, что...» 


FN Обязательно почитайте прекрасный цикл статей «The 7 Plagues of Software Testing»!4 
(James Whittaker). 


Итак: «А я думал(а), что...» / «А правда ли, что...» 


НЕНАДО РАЗБИРАТЬСЯ В КОМПЬЮТЕРАХ 


Без комментариев. Нет, возможно, существуют некие ничтожно малые доли процента деятель- 
ности тестировщика, которую можно реализовать «на пальцах». Но этой бесконечно малой ве- 
личиной можно пренебречь. 


ОБЯЗАТЕЛЬНО НАДО ХОРОШО ЗНАТЬ ПРОГРАММИРОВАНИЕ 


Очень больно относить эту мысль к мифам. Хорошо, когда тестировщик знает программиро- 
вание. Ещё лучше, когда он знает его хорошо. Но даже общих отдалённых представлений о про- 
граммировании хватает для начала карьеры. А дальше уже — по обстоятельствам. 


В ТЕСТИРОВАНИИ ВСЁ ПРОСТО 


Если развить аналогию, то и в кулинарии всё просто, если мы говорим о заваривании чая в 
пакетике. Но как подобным чаем не заканчивается кулинария, так и тестирование не заканчи- 
вается случаями «ой, тут вот картинка не загрузилась». Даже на исключительно практическом 
уровне задачи тестирования могут быть сопоставимы по сложности с задачами проектирования 
и разработки программ (хм, почему ж нет мифа «программирование — это просто», ведь «Hello, 
world» написать не тяжело). А если мы посмотрим на «надёжность программного обеспечения» 
с научной точки зрения, то перспективы роста сложности вообще ничем не ограничены. Обяза- 
тельно ли каждому тестировщику «лезть в эти дебри»? Нет. Но если хочется — можно. К тому же 
это очень интересно. 


14 «The plague of repetitiveness», James Whittaker [http://googletesting.blogspot.com/2009/06/by-james.html] 

“The Plague of Amnesia», James Whittaker [http://googletesting.blogspot.com/2009/07/plague-of-amnesia.html] 

“The Plague of Boredom», James Whittaker [http://googletesting.blogspot.com/2009/07/plague-of-boredom.html] 

“The Plague of Homelessness», James Whittaker [http://googletesting.blogspot.com/2009/07/plague-of-homelessness.html] 
“The Plague of Blindness», James Whittaker [http://googletesting.blogspot.com/2009/07/plague-of-blindness.html] 

“The 7th Plague and Beyond», James Whittaker [http://googletesting.blogspot.com/2009/09/7th-plague-and-beyond.html] 
«Те Plague of Entropy», James Whittaker [http://googletesting.blogspot.com/2009/09/plague-of-entropy.html] 
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В ТЕСТИРОВАНИИ КУЧА РУТИНЫ И СКУКИ 


Не больше и не меньше, чем в иных ГТ-профессиях. Остальное зависит от конкретного тести- 
ровщика и того, как он организует свою работу. 


ТЕСТИРОВЩИКА ДОЛЖНЫ ВСЕМУ-ВСЕМУ НАУЧИТЬ 


Не должны. И уж тем более «всему-всему». Да, если мы говорим о явно обозначенном учебном 
процессе, то его организаторы (будь то предмет в университете, учебный курс в некоем тренин- 
говом центре или отдельный тренинг внутри компании) часто берут на себя определённые «пе- 
дагогические обязательства». Но подобная учебная деятельность никогда не заменит саморазви- 
тия (хотя и может в нужный момент помочь в выборе направления пути). ГТ-отрасль меняется 
очень интенсивно и непрерывно. Учиться придётся до пенсии. 


В ТЕСТИРОВЩИКИ ИДУТТЕ, КТО НЕ СМОГ СТАТЬ ПРОГРАММИСТОМ 


А в скрипачи — те, кто не смог стать пианистом? Я думаю, что некий небольшой процент «не 
ставших программистами» в тестировании есть. Но он теряется на фоне тех, кто шёл в тестиро- 
вание изначально и сознательно, а также тех, кто пришёл в тестирование из программирования. 


В ТЕСТИРОВАНИИ СЛОЖНО ПОСТРОИТЬ КАРЬЕРУ 


При должном старании карьера в тестировании оказывается едва ли не самой динамичной 
(по сравнению с другими ІТ-направлениями). Тестирование само по себе — очень бурно раз- 
вивающаяся отрасль ЇТ, и здесь всегда можно выбрать что-то, что будет вам очень нравиться и 
хорошо получаться — а в таких условиях стать профессионалом и достичь успеха легко. 


ТЕСТИРОВЩИК «ВИНОВАТ ВО ВСЁМ», Т. Е. С НЕГО СПРОСЗА ВСЕ ОШИБКИ 


Только если признать, что в болезни пациента виновен термометр, показывающий высокую 
температуру. Скорее с тестировщиков будет спрос за те ошибки, что были найдены пользовате- 
лем, т. е. проявились уже на стадии реальной эксплуатации продукта. Но и здесь нет однозначно- 
го вывода — за конечный успех продукта отвечает вся команда, и было бы глупо перекладывать 
ответственность лишь на одну её часть. 


ТЕСТИРОВЩИКИ СКОРО БУДУТ НЕНУЖНЫ, Т.К. ВСЁ БУДЕТ АВТОМАТИЗИРОВАНО 


Как только по улицам забегают терминаторы — да, этот миф станет правдой: программы на- 
учатся обходиться без людей. Но тогда у нас всех будут другие проблемы. А если кроме шуток, 
человечество уже сотни лет идёт по пути автоматизации, которая накладывает свой отпечаток 
на всю нашу жизнь и чаще всего позволяет переложить самую простую и не требующую квали- 
фикации работу на машины. Но кто же заставляет вас оставаться на уровне исполнителя такой 
работы? Начиная с некоторого уровня, тестирование превращается в гармоничное сочетание 
науки и искусства. А многих ли учёных или творцов заменила автоматизация? 


вании...» / «А правда ли, что в тестировании...». Если так, поделитесь ими, пожалуй- 


© Просьба: возможно, у вас есть какие-то мысли из разряда «А я думал(а), что в тестиро- 
ста, в анонимном опросе: http://svyatoslav.biz/software_testing_book_poll/ 
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ОСНОВНЫЕ ЗНАНИЯ 
И УМЕНИЯ 


РАЗДЕЛ 


ПРОЦЕССЫ ТЕСТИРОВАНИЯ 
И РАЗРАБОТКИ ПО 


2.1.1. МОДЕЛИ РАЗРАБОТКИ ПО namm 


Чтобы лучше разобраться в том, как тестирование соотносится с программированием и ины- 
ми видами проектной деятельности, для начала рассмотрим самые основы — модели разработки 
(lifecycle то4е!>) ПО (как часть жизненного цикла (software lifecycle16) ПО). При этом сразу под- 
черкнём, что разработка ПО является лишь частью жизненного цикла ПО, и здесь мы говорим 
именно о разработке. 

Материал данной главы относится скорее к дисциплине «управление проектами», потому 
здесь рассмотрен крайне сжато: пожалуйста, не воспринимайте его как исчерпывающее руковод- 
ство — здесь едва ли рассмотрена и сотая доля процента соответствующей предметной области. 


Модель разработки ПО (Software Development Model, SDM) — структура, системати- 
зирующая различные виды проектной деятельности, их взаимодействие и последова- 
тельность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба 
и сложности проекта, предметной области, доступных ресурсов и множества других 
факторов. 


Выбор модели разработки ПО серьёзно влияет на процесс тестирования, определяя выбор 
стратегии, расписание, необходимые ресурсы и т.д. 

Моделей разработки ПО много, но в общем случае классическими можно считать водопадную, 
у-образную, итерационную инкрементальную, спиральную и гибкую. 


15 Lifecycle model. А partitioning of the Ше of a product ог project into phases. [ISTQB Glossary] 

16 Software lifecycle. The period of time that begins when a software product is conceived and ends when the software 
is no longer available for use. The software lifecycle typically includes a concept phase, requirements phase, design phase, 
implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement 
phase. Note these phases may overlap or be performed iteratively. [ISTQB Glossary] 
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С Перечень моделей разработки ПО (с кратким описанием), рекомендуемых к изучению 
тестировщиками, можно найти в статье «What аге ће Software Development Мо4е!з3»17. 


Знать и понимать модели разработки ПО необходимо затем, чтобы уже с первых дней рабо- 
ты понимать, что происходит вокруг, что, зачем и почему вы делаете. Многие начинающие тес- 
тировщики отмечают, что ощущение бессмысленности происходящего посещает их, даже если 
текущие задания интересны. Чем полнее вы будете представлять картину происходящего на 
проекте, тем яснее вам будет виден ваш собственный вклад в общее дело и смысл того, чем вы 
занимаетесь. 

Ещё одна важная вещь, которую следует понимать, состоит в том, что никакая модель не яв- 
ляется догмой или универсальным решением. Нет идеальной модели. Есть та, которая хуже или 
лучше подходит для конкретного проекта, конкретной команды, конкретных условий. 


вольной трактовки модели и перекраивания её «на свой вкус» без кристально чёткого 
понимания, что и зачем вы делаете. О том, что бывает при нарушении логики модели, 
прекрасно сказал в своём слайдкасте «Scrum Tailoring»!8 Максим Дорофеев. 


@ Частая ошибка! Единственное, от чего стоит предостеречь уже сейчас, так это от фри- 


Водопадная модель (waterfall modell’) сейчас представляет скорее исторический интерес, 
т. к. в современных проектах практически неприменима. Она предполагает однократное выпол- 
нение каждой из фаз проекта, которые, в свою очередь, строго следуют друг за другом (рису- 
нок 2.1.а). Очень упрощённо можно сказать, что в рамках этой модели в любой момент времени 
команде «видна» лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится 
«видеть весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить недора- 
ботки или что-то уточнить. 

К недостаткам водопадной модели принято относить тот факт, что участие пользователей ПО 
в ней либо не предусмотрено вообще, либо предусмотрено лишь косвенно на стадии однократ- 
ного сбора требований. С точки зрения же тестирования эта модель плоха тем, что тестирование 
в явном виде появляется здесь лишь с середины развития проекта, достигая своего максимума в 
самом конце. 

Тем не менее водопадная модель часто интуитивно применяется при выполнении относитель- 
но простых задач, а её недостатки послужили прекрасным отправным пунктом для создания 
новых моделей. Также эта модель в несколько усовершенствованном виде используется на круп- 
ных проектах, в которых требования очень стабильны и могут быть хорошо сформулированы в 
начале проекта (аэрокосмическая область, медицинское ПО ит.д.) 


= Относительно краткое и притом хорошее описание водопадной модели можно найти в 
© статье «What is Waterfall model advantages, disadvantages and when to use >29. 


Великолепное описание истории развития и заката водопадной модели было создано 
Максимом Дорофеевым в виде слайдкаста «The Rise And Fall Of Waterfall», который 
можно посмотреть?! в его ЖЖ. 


17 «What аге ће Software Development Models?» [http://istqbexamcertification.com/what-are-the-software-development- 
models/] 

18 «Scrum Tailoring», Максим Дорофеев [http://cartmendum.livejournal.com/10862.html] 

19 In a waterfall model, each phase must be completed fully before the next phase can begin. This type of model is basically 
used for the project which is small and there are no uncertain requirements. At the end of each phase, a review takes place to 
determine if the project is on the right path and whether or not to continue or discard the project. [http://istqbexamcertification. 
com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/] 

20 «What is Waterfall model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is- 
waterfall-model-advantages-disadvantages-and-when-to-use-it/] 

21 ЖЖ Максима Дорофеева. [http://cartmendum.livejournal.com/44064.html] 
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Рисунок 2.1.а — Водопадная модель разработки ПО 


У-образная модель (V-model??) является логическим развитием водопадной. Можно заметить 
(рисунок 2.1.Ъ), что в общем случае как водопадная, так и у-образная модели жизненного цикла 
ПО могут содержать один и тот же набор стадий, но принципиальное отличие заключается в 
том, как эта информация используется в процессе реализации проекта. 

Очень упрощённо можно сказать, что при использовании у-образной модели на каждой ста- 
дии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии 
«на подъёме». Тестирование здесь появляется уже на самых ранних стадиях развития проекта, 
что позволяет минимизировать риски, а также обнаружить и устранить множество потенциаль- 
ных проблем до того, как они станут проблемами реальными. 


22 V-model. А framework to describe the software development lifecycle activities from requirements specification to 
maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software development 
lifecycle. [ISTQB Glossary] 
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Рисунок 2.1.6 — У-образная модель разработки ПО 


ages, disadvantages апа when to use it?»?3. Пояснение по использованию У-образной MO- 


© Краткое описание у-образной модели можно найти в статье «What 15 V-model advant- 
дели в тестировании можно найти в статье «Using V Models Юг Testing»?4. 


Итерационная инкрементальная модель (iterative по4е!25, incremental model?) является 
фундаментальной основой современного подхода к разработке ПО. Как следует из названия мо- 
дели, ей свойственна определённая двойственность (а [$ ТОВ-глоссарий даже не приводит едино- 
го определения, разбивая его на отдельные части): 


e сточки зрения жизненного цикла модель является итерационной, т.к. подразумевает MHO- 
гократное повторение одних и тех же стадий; 

e с точки зрения развития продукта (приращения его полезных функций) модель является 
инкрементальной. 


Ключевой особенностью данной модели является разбиение проекта на относительно неболь- 
шие промежутки (итерации), каждый из которых в общем случае может включать в себя все 
классические стадии, присущие водопадной и у-образной моделям (рисунок 2.1.с). Итогом ите- 
рации является приращение (инкремент) функциональности продукта, выраженное в промежу- 
точном билде (build?”). 


23 «What is V-model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is-v-model- 
advantages-disadvantages-and-when-to-use-it/] 

24 «Using V Models for Testing», Donald Firesmith [http://blog.sei.cmu.edu/post.cfm/using-v-models-testing-315] 

25 Iterative development model. A development lifecycle where a project is broken into a usually large number of iterations. 
An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of 
the final product under development, which grows from iteration to iteration to become the final product. [ISTQB Glossary] 

26 Incremental development model. A development lifecycle where a project is broken into a series of increments, each of 
which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered 
in priority order in the appropriate increment. In some (but not all) versions of this lifecycle model, each subproject follows a 
‘mini У-тоде] with its own design, coding and testing phases. [ISTQB Glossary] 

27 Build. A development activity whereby a complete system is compiled and linked, so that a consistent system is available 
including all latest changes. [На основе определения термина «daily build» ns ISTQB Glossary] 
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Рисунок 2.1.с — Итерационная инкрементальная модель разработки ПО 


Длина итераций может меняться в зависимости от множества факторов, однако сам принцип 
многократного повторения позволяет гарантировать, что и тестирование, и демонстрация про- 
дукта конечному заказчику (с получением обратной связи) будет активно применяться с самого 
начала и на протяжении всего времени разработки проекта. 

Во многих случаях допускается распараллеливание отдельных стадий внутри итерации и ак- 
тивная доработка с целью устранения недостатков, обнаруженных на любой из (предыдущих) 
стадий. 

Итерационная инкрементальная модель очень хорошо зарекомендовала себя на объёмных и 
сложных проектах, выполняемых большими командами на протяжении длительных сроков. Од- 
нако к основным недостаткам этой модели часто относят высокие накладные расходы, вызван- 


ные высокой «бюрократизированностью» и общей громоздкостью модели. 


Относительно краткие и очень хорошие описания итерационной инкрементальной MO- 
дели можно найти в статьях «What is Iterative model advantages, disadvantages and when 
to use it?»?8 и «What is Incremental model advantages, disadvantages and when to use 1»29. 


Спиральная модель (spiral то4е!30) представляет собой частный случай итерационной MH- 
крементальной модели, в котором особое внимание уделяется управлению рисками, в особенно- 
сти влияющими на организацию процесса разработки проекта и контрольные точки. 


28 «What is Iterative model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is- 
iterative-model-advantages-disadvantages-and-when-to-use-it/] 

29 «What is Incremental model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is- 
incremental-model-advantages-disadvantages-and-when-to-use-it/] 

30 Spiral model. A software lifecycle model which supposes incremental development, using the waterfall model for each 
step, with the aim of managing risk. In the spiral model, developers define and implement features in order of decreasing 
priority. [http://dictionary.reference.com/browse/spiral+model] 
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Рисунок 2.1.4 — Спиральная модель разработки ПО 


Схематично суть спиральной модели представлена на рисунке 2.1.4. Обратите внимание нато, 
что здесь явно выделены четыре ключевые фазы: 


e проработка целей, альтернатив и ограничений; 
• анализ рисков и прототипирование; 

e разработка (промежуточной версии) продукта; 
• планирование следующего цикла. 


С точки зрения тестирования и управления качеством повышенное внимание рискам являет- 
ся ощутимым преимуществом при использовании спиральной модели для разработки концеп- 
туальных проектов, в которых требования естественным образом являются сложными и неста- 
бильными (могут многократно меняться по ходу выполнения проекта). 
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Автор модели Barry Boehm в своих публикациях3\3? подробно раскрывает эти вопросы и 
приводит множество рассуждений и рекомендаций о том, как применять спиральную модель с 
максимальным эффектом. 


fN Относительно краткие и очень хорошие описания спиральной модели можно найти в 
© статьях «What is Spiral model- advantages, disadvantages and when to use 133 и «Spiral 
Model»34, 


Гибкая модель (agile то4е!35) представляет собой совокупность различных подходов к разра- 
ботке ПО и базируется на т.н. «аз|е-манифесте»36: 


• Люди и взаимодействие важнее процессов и инструментов. 

e Работающий продукт важнее исчерпывающей документации. 

» Сотрудничество с заказчиком важнее согласования условий контракта. 
• Готовность к изменениям важнее следования первоначальному плану. 


стоит почитать эти книги: 
e «Agile Testing» (Lisa Crispin, Janet Gregory). 
• «Essential Scrum» (Kenneth S. Rubin). 


© Данная тема является настолько большой, что ссылок на статьи недостаточно, а потому 


Как несложно догадаться, положенные в основу гибкой модели подходы являются логиче- 
ским развитием и продолжением всего того, что было за десятилетия создано и опробовано в 
водопадной, у-образной, итерационной инкрементальной, спиральной и иных моделях. Причём 
здесь впервые был достигнут ощутимый результат в снижении бюрократической составляющей 
и максимальной адаптации процесса разработки ПО к мгновенным изменениям рынка и требо- 
ваний заказчика. 

Очень упрощённо (почти на грани допустимого) можно сказать, что гибкая модель представ- 
ляет собой облегчённую с точки зрения документации смесь итерационной инкрементальной 
и спиральной моделей (рисунки 2.1.е37, 2.1.f); при этом следует помнить об «аріїе-манифесте» и 
всех вытекающих из него преимуществах и недостатках. 

Главным недостатком гибкой модели считается сложность её применения к крупным проек- 
там, а также частое ошибочное внедрение её подходов, вызванное недопониманием фундамен- 
тальных принципов модели. 

Тем не менее можно утверждать, что всё больше и больше проектов начинают использовать 
гибкую модель разработки. 

О Очень подробное и элегантное изложение принципов применения гибкой модели раз- 
работки ПО можно найти в статье «The Agile System Development Life Суе»38. 


31 «А Spiral Model of Software Development and Enhancement», Barry Boehm [http://csse.usc.edu/csse/TECHRPTS/1988/ 
usccse88-500/usccse88-500.pdf] 


32 «Spiral Development: Experience, Principles, and Refinements», Barry Boehm. [http://www.sei.cmu.edu/reports/ 
005г008.рағ 


33 «What is Spiral model - advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is- 
spiral-model-advantages-disadvantages-and-when-to-use-it/] 


34 «Spiral Model», Amir Ghahrai. [http://www.testingexcellence.com/spiral-model/] 


35 Agile software development. A group of software development methodologies based on EITP iterative incremental 
development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. 
[ISTQB Glossary] 


36 «Аріїе-манифест» [http://agilemanifesto.org/iso/ru/manifesto.html] 
37 Оригинал рисунка и исходный материал: http://www.gtagile.com/GT_Agile/Home.html 
38 «The Agile System Development Life Cycle» [http://www.ambysoft.com/essays/agileLifecycle.html] 
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Рисунок 2.1.е — Суть гибкой модели разработки ПО 
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Рисунок 2.1. — Итерационный подход в рамках гибкой модели и scrum 


Вкратце можно выразить суть моделей разработки ПО таблицей 2.1.а. 


Таблица 2.1.а — Сравнение моделей разработки ПО 


Модель Преимущества Недостатки Тестирование 
У каждой стадии есть 
_у i Й • Полная неспособность 
чёткий проверяемый 
адаптировать проект 
результат. 
Е к изменениям в требо- 
В каждый момент времени • С середины 
Водопадная ваниях. 
команда выполняет один . проекта. 
e Крайне позднее 
вид работы. 
создание работающего 
Хорошо работает 
продукта. 
для небольших задач. 
У каждой стадии есть e Недостаточная 
чёткий проверяемый гибкость 
результат. и адаптируемость. 
Внимание тестированию |e Отсутствует раннее 
„ e На переходах 
\У-образная уделяется с первой же прототипирование. 


стадии. 
Хорошо работает 
для проектов со стабиль- 


НЫМИ требованиями. 


e Сложность устранения 


проблем, пропущен- 
ных на ранних стадиях 
развития проекта. 


между стадиями. 
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Таблица 2.1.а [окончание] 
Модель Преимущества Недостатки Тестирование 
• Недостаточная 
Достаточно раннее прото- 
гибкость внутри 
типирование. А 
Итерационная итераций. 
Простота управления 
инкремен- • Сложность устранения 
итерациями. 
тальная ои орою проблем, пропущен- 
на управляемые с айй РАИ СтеДИах „Б ошедепганы; 
упр рации. развития проекта. моменты итераций. 
• Повторное 
тестирование 
e Высокие накладные (после доработки) 
; асходы. 
Глубокий анализ рисков. р TEE MPOREPENHOLO 
e Сложность примене- анее 
Подходит для крупных Р . 
ния для небольших 
Спиральная проектов. 


Достаточно раннее прото- 
типирование. 


проектов. 

e Высокая зависимость 
успеха от качества 
анализа рисков. 


Гибкая 


Максимальное вовлечение 
заказчика. 

Много работы с требова- 
ниями. 

Тесная интеграция тести- 
рования и разработки. 
Минимизация докумен- 
тации. 


© Ещё два кратких и информативных 


© 


• Сложность реали- 
зации для больших 
проектов. 

e Сложность постро- 
ения стабильных 
процессов. 


• В определённые 
моменты итераций 
и влюбой необхо- 
димый момент. 


сравнения моделей жизненного цикла ПО мож- 
но найти в статьях «Project Lifecycle Models: How They Differ апа When ќо Use Them»3? 
и «Блок-схема выбора оптимальной методологии разработки ПО»40. А общий обзор 
всех моделей в контексте тестирования ПО представлен в статье «What аге the Software 
Development Мо4е13»41. 


Задание 2.1.а: представьте, что на собеседовании вас попросили назвать основные мо- 
дели разработки ПО, перечислить их преимущества и недостатки с точки зрения тести- 
рования. Не ждите собеседования, ответьте на этот вопрос сейчас, а ответ запишите. 


39 «Project Lifecycle Models: How They Differ and When to Use Them» [http://www.business-esolutions.com/islm.htm] 
40 «Блок-схема выбора оптимальной методологии разработки ПО» [http://megamozg.ru/post/23022/] 


41 «What аге the Software Development Models?» [http://istqbexamcertification.com/what-are-the-software-development- 


models/] 
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2.1.2. ЖИЗНЕННЫЙ ЦИКЛ ТЕСТИРОВАНИЯ mumm 


Следуя общей логике итеративности, превалирующей во всех современных моделях разработ- 
ки ПО, жизненный цикл тестирования также выражается замкнутой последовательностью дей- 
ствий (рисунок 2.1.5). 


Общее планирование и 
анализ требований 


Уточнение критериев 


Отчётность д 
приёмки 


Анализ результатов Уточнение стратегии 
тестирования тестирования 


Фиксация найденных 
дефектов 


Разработка тест-кейсов 


Выполнение тест- 
кейсов 


Рисунок 2.1.5 — Жизненный цикл тестирования 


Важно понимать, что длина такой итерации (и, соответственно, степень подробности каждой 
стадии) может варьироваться в широчайшем диапазоне — от единиц часов до десятков месяцев. 
Как правило, если речь идёт о длительном промежутке времени, он разбивается на множество 
относительно коротких итераций, но сам при этом «тяготеет» к той или иной стадии в каждый 
момент времени (например, в начале проекта больше планирования, в конце — больше отчёт- 
ности). 

Также ещё раз подчеркнём, что приведённая схема — не догма, и вы легко можете найти аль- 
тернативы (например, здесьї? и specht), но общая суть и ключевые принципы остаются неиз- 
менными. Их и рассмотрим. 

Стадия 1 (общее планирование и анализ требований) объективно необходима как минимум 
для того, чтобы иметь ответ на такие вопросы, как: что нам предстоит тестировать; как много 
будет работы; какие есть сложности; всё ли необходимое у нас есть и т.п. Как правило, получить 
ответы на эти вопросы невозможно без анализа требований, т.к. именно требования являются 
первичным источником ответов. 


42 «Software Testing Life Cycle» [http://softwaretestingfundamentals.com/software-testing-life-cycle/] 
43 «Software Testing Life Cycle» [http://www.softwaretestingmentor.com/stlc/software-test-life-cycle/] 
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Стадия 2 (уточнение критериев приёмки) позволяет сформулировать или уточнить метрики 
и признаки возможности или необходимости начала тестирования (entry сгіќегіа&), приостанов- 
ки (suspension сгїегїа#°) и возобновления (resumption criteria46) тестирования, завершения или 
прекращения тестирования (exit сгїїегїа*7). 

Стадия 3 (уточнение стратегии тестирования) представляет собой ещё одно обращение к пла- 
нированию, но уже на локальном уровне: рассматриваются и уточняются те части стратегии те- 
стирования (test ѕігаѓеру“8), которые актуальны для текущей итерации. 

Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру, уточнению, доработке, 
переработке и прочим действиям с тест-кейсами, наборами тест-кейсов, тестовыми сценариями 
и иными артефактами, которые будут использоваться при непосредственном выполнении тести- 
рования. 

Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефектов) тесно связаны 
между собой и фактически выполняются параллельно: дефекты фиксируются сразу по факту 
их обнаружения в процессе выполнения тест-кейсов. Однако зачастую после выполнения всех 
тест-кейсов и написания всех отчётов о найденных дефектах проводится явно выделенная ста- 
дия уточнения, на которой все отчёты о дефектах рассматриваются повторно с целью формиро- 
вания единого понимания проблемы и уточнения таких характеристик дефекта, как важность и 
срочность. 

Стадия 7 (анализ результатов тестирования) и стадия 8 (отчётность) также тесно связаны 
между собой и выполняются практически параллельно. Формулируемые на стадии анализа ре- 
зультатов выводы напрямую зависят от плана тестирования, критериев приёмки и уточнённой 
стратегии, полученных на стадиях 1, 2 и 3. Полученные выводы оформляются на стадии 8 и слу- 
жат основой для стадий 1, 2 и 3 следующей итерации тестирования. Таким образом, цикл замы- 
кается. 


В жизненном цикле тестирования пять из восьми стадий так или иначе связаны с управлени- 
ем проектами, рассмотрение которого не входит в наши планы, а потому обо всём, что касается 
планирования и отчётности, мы кратко поговорим в главе «Оценка трудозатрат, планирование и 
отчётность» {206}. А сейчас мы переходим к ключевым навыкам и основным видам деятельности 
тестировщиков и начнём с работы с документацией. 


44 Entry criteria. The set of generic and specific conditions Юг permitting а process to go forward with а defined task, e.g. 
test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to 
the effort needed to remove the failed entry criteria. [ISTQB Glossary] 

45 Suspension criteria. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. 
[ISTQB Glossary] 

46 Resumption criteria. The criteria used to restart all or a portion of the testing activities that were suspended previously. 
[ISTQB Glossary] 

47 Fxit criteria. The set of generic and specific conditions, agreed upon with the stakeholders for permitting a process to 
be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still 
outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop 
testing. [ISTQB Glossary] 

48 Test strategy. A high-level description of the test levels to be performed and the testing within those levels for an 
organization or program (one or more projects). [ISTQB Glossary] 
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ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ 
И ТРЕБОВАНИИ 


2.2.1. ЧТО ТАКОЕ «ТРЕБОВАНИЕ» ташая 


Как мы только что рассмотрели в главе, посвящённой жизненному циклу тестирования, всё 
так или иначе начинается с документации и требований. 


Требование (requirement?) — описание того, какие функции и с соблюдением каких 
условий должно выполнять приложение в процессе решения полезной для пользова- 
теля задачи. 


тературе 10-20-30-летней давности, то можно заметить, что изначально о пользовате- 
лях, их задачах и полезных для них свойствах приложения в определении требования 
не было сказано. Пользователь выступал некоей абстрактной фигурой, не имеющей от- 
ношения к приложению. В настоящее время такой подход недопустим, т. к. он не толь- 
ко приводит к коммерческому провалу продукта на рынке, но и многократно повышает 
затраты на разработку и тестирование. 


© Небольшое «историческое отступление»: если поискать определения требований в JIN- 


Хорошим кратким предисловием ко всему тому, что будет рассмотрено в данной главе, 
можно считать небольшую статью «What is documentation testing in software їезїїпд»?0. 


49 Requirement. A condition or capability needed by a user to solve a problem or achieve an objective that must be met or 
possessed by a system or system component to satisfy a contract, standard, specification, or other formally im-posed document. 
[ISTQB glossary] 

50 «What is documentation testing in software testing». [http://istqbexamcertification.com/what-is-documentation- 
testing/] 
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2.2.2. ВАЖНОСТЬ ТРЕБОВАНИЙ mmm 


Требования являются отправной точкой для определения того, что проектная команда будет 
проектировать, реализовывать и тестировать. Элементарная логика говорит нам, что если в тре- 
бованиях что-то «не то», то и реализовано будет «не то», т.е. колоссальная работа множества 
людей будет выполнена впустую. Эту мысль иллюстрирует рисунок 2.2.а. 


Стоимость 
А исправления 
ошибки 
1000 
500 
20 
Время, 
затраченное 
0 на проект 
г> 
Общее Системные Детализированный Интеграция и Системное Итоговая 
планирование требования дизайн модульные тесты тестирование отчётность 


Пользовательские 
требования 


Техническая 
архитектура 


Разработка и 
отладка 


Инсталляционное 
тестирование 


Приёмочное 
тестирование 


Эксплуатация 


Рисунок 2.2.а — Стоимость исправления ошибки в зависимости от момента её обнаружения 


Брайан Хэнкс, описывая важность требований5!, подчёркивает, что они: 


• Позволяют понять, что и с соблюдением каких условий система должна делать. 

• Предоставляют возможность оценить масштаб изменений и управлять изменениями. 

• Являются основой для формирования плана проекта (в том числе плана тестирования). 
e Помогают предотвращать или разрешать конфликтные ситуации. 

e Упрощают расстановку приоритетов в наборе задач. 

• Позволяют объективно оценить степень прогресса в разработке проекта. 


Вне зависимости от того, какая модель разработки ПО используется на проекте, чем позже бу- 
дет обнаружена проблема, тем сложнее и дороже будет её решение. А в самом начале («водопада», 
«спуска по букве У», «итерации», «витка спирали») идёт планирование и работа с требованиями. 

Если проблема в требованиях будет выяснена на этой стадии, её решение может свестись к 
исправлению пары слов в тексте, в то время как недоработка, вызванная пропущенной пробле- 
мой в требованиях и обнаруженная на стадии эксплуатации, может даже полностью уничтожить 
проект. 

Если графики вас не убеждают, попробуем проиллюстрировать ту же мысль на простом при- 
мере. Допустим, вы с друзьями составляете список покупок перед поездкой в гипермаркет. Вы 


51 «Requirements in the Real 
requirementsLecture.pdf] 


World», Brian Hanks [https://classes.soe.ucsc.edu/cmps109/Winter02/notes/ 
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поедете покупать, а друзья ждут вас дома. Сколько «стоит» дописать, вычеркнуть или изменить 
пару пунктов, пока вы только-только составляете список? Нисколько. Если мысль о несовершен- 
стве списка настигла вас по пути в гипермаркет, уже придётся звонить (дёшево, но не бесплатно). 
Если вы поняли, что в списке «что-то не то» в очереди на кассу, придётся возвращаться в тор- 
говый зал и тратить время. Если проблема выяснилась по пути домой или даже дома, придётся 
вернуться в гипермаркет. И, наконец, клинический случай: в списке изначально было что-то уж 
совсем неправильное (например, «100 кг конфет — и всё»), поездка совершена, все деньги потра- 
чены, конфеты привезены и только тут выясняется, что «ну мы же пошутили». 


Задание 2.2.а: представьте, что ваш с друзьями бюджет ограничен, и в списке требова- 
ний появляются приоритеты (что-то купить надо обязательно, что-то, если останутся 
деньги, и т.п.). Как это повлияет на риски, связанные с ошибками в списке? 


Ещё одним аргументом в пользу тестирования требований является то, что, по разным оцен- 
кам, в них зарождается от % до % всех проблем с программным обеспечением. В итоге есть риск, 
что получится так, как показано на рисунке 2.2.b. 

Поскольку мы постоянно говорим «документация и требования», а не просто «требования», 
то стоит рассмотреть перечень документации, которая должна подвергаться тестированию в 
процессе разработки ПО (хотя далее мы будем концентрироваться именно на требованиях). 

В общем случае документацию можно разделить на два больших вида в зависимости от вре- 
мени и места её использования (здесь будет очень много сносок с определениями, т. к. по видам 
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менеджер проекта описал проект реализовал проект 

хочет консультантами 


Так проект был В такую сумму Так работала Что на самом деле 
сдан в проект обошёлся техническая было нужно 
эксплуатацию заказчику поддержка клиенту 


Так проект был 
задокументирован 


Рисунок 2.2.6 — Типичный проект с плохими требованиями 
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документации очень часто поступает множество вопросов и потому придётся рассмотреть неко- 
торые моменты подробнее). 


e Продуктная документация (product documentation, development documentation’?) исполь- 
зуется проектной командой во время разработки и поддержки продукта. Она включает: 


° План проекта (project management рІап>3) и в том числе тестовый план (test р1ап5“). 

° Требования к программному продукту (product requirements document, PRD>>) и функ- 
циональные спецификации (functional specification’ document, FSD37; software require- 
ments specification, $6558). 

° Архитектуру и дизайн (architecture апа еѕісп>9). 

° Тест-кейсы и наборы тест-кейсов (test саѕеѕ60, test вшїе$®1). 

° Технические спецификации (technical specifications6?), такие как схемы баз данных, опи- 
сания алгоритмов, интерфейсов и т. д. 


52 Development documentation. Development documentation comprises those documents that propose, specify, plan, 
review, test, and implement the products of development teams in the software industry. Development docu-ments include 
proposals, user or customer requirements description, test and review reports (suggesting product improvements), and self- 
reflective documents written by team members, analyzing the process from their perspective. [«Ооситепќайоп for software 
and IS development», Thomas T. Barker] 

53 Project management plan. A formal, approved document that defines how the project is executed, monitored and 
controlled. It may be summary or detailed and may be composed of one of more subsidiary management plans and other 
planning documents. [PMBOK, 3" d edition] 

54 Test plan. A document describing the scope, approach, resources and schedule of intended test activities. It identifies 
amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, 
the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any 
risks requiring contingency planning. It is a record of the test planning process. [ISTQB Glossary] 

55 Product requirements document, PRD. The PRD describes the product your company will build. It drives the efforts 
of the entire product team and the company’s sales, marketing and customer support efforts. The purpose of the product 
requirements document (PRD) or product spec is to clearly and unambiguously articulate the products purpose, features, 
functionality, and behavior. The product team will use this specification to actually build and test the product, so it needs to 
be complete enough to provide them the information they need to do their jobs. [«Ноу to write a good PRD», Martin Сарап] 

56 Specification. A document that specifies, ideally in a complete, precise and verifiable manner, the requirements, design, 
behavior, or other characteristics of a component or system, and, often, the procedures for determining whether these provisions 
have been satisfied. [ISTQB Glossary] 

57 Functional specifications document, FSD. Cm. «Software requirements specification, SRS». 

58 Software requirements specification, SRS. SRS describes as fully as necessary the expected behavior of the software 
system. The SRS is used in development, testing, quality assurance, project management, and related project functions. People 
call this deliverable by many different names, including business requirements document, functional spec, requirements 
document, and others. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beat-ty] 

59 Architecture. Design. A software architecture for a system is the structure or structures of the system, which comprise 
elements, their externally-visible behavior, and the relationships among them. ... Architecture is design, but not all design is 
architecture. Thatis, there are many design decisions that are left unbound by the architecture, and are happily left to the discretion 
and good judgment of downstream designers and implementers. The architecture establishes constraints on downstream 
activities, and those activities must produce artifacts (finer-grained designs and code) that are compliant with the architecture, 
but architecture does not define an implementation. [«Documenting Software Architectures», Paul Clements и др.] Очень 
подробное описание различия архитектуры и дизайна можно найти в статье «Architecture, Design, Implementation», 
Ammon Eden, Rick Kazman. [http://www.eden-study.org/articles/2003/icse03.pdf] 

60 Test case. A set of input values, execution preconditions, expected results and execution postconditions, developed for 
a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific 
requirement. [ISTQB Glossary] 

6l Test suite. A set of several test cases for a component or system under test, where the post condition of one test is often 
used as the precondition for the next one. [ISTQB Glossary] 

62 Technical specifications. Scripts, source code, data definition language, etc. [PMBOK, 3rd edition] Также см. 
«Specification». 
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Проектная документация 


Продуктная 
документация 


Рисунок 2.2.с — Соотношение понятий «продуктная документация» 
и «проектная документация» 


• Проектная документация (project documentation?) включает в себя как продуктную доку- 
ментацию, так и некоторые дополнительные виды документации и используется не только 
на стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедре- 
ния и эксплуатации). Она включает: 


° Пользовательскую и сопроводительную документацию (user and accompanying docu- 
тепќайопёї), такую как встроенная помощь, руководство по установке и использова- 
нию, лицензионные соглашения и т.д. 

° Маркетинговую документацию (market requirements document, MRD65), которую пред- 
ставители разработчика или заказчика используют как на начальных этапах (для уточ- 
нения сути и концепции проекта), так и на финальных этапах развития проекта (для 
продвижения продукта на рынке). 


В некоторых классификациях часть документов из продуктной документации может быть пе- 
речислена в проектной документации — это совершенно нормально, т. к. понятие проектной 
документации по определению является более широким. Поскольку с этой классификацией 
связано очень много вопросов и непонимания, отразим суть ещё раз — графически (см. рису- 
нок 2.2.с) — и напомним, что мы договорились классифицировать документацию по признаку 
того, где (для чего) она является наиболее востребованной. 

Степень важности и глубина тестирования того или иного вида документации и даже отдель- 
ного документа определяется большим количеством факторов, но неизменным остаётся общий 
принцип: всё, что мы создаём в процессе разработки проекта (даже рисунки маркером на доске, 
даже письма, даже переписку в скайпе), можно считать документацией и так или иначе подвер- 
гать тестированию (например, вычитывание письма перед отправкой — это тоже своего рода 
тестирование документации). 


63 Project documentation. Other expectations and deliverables that are not а part of the software the team implements, but 
that are necessary to the successful completion of the project as a whole. [«Software Requirements (31d edition)», Karl Wiegers 
and Joy Beatty] 

64 User documentation. User documentation refers to the documentation for a product or service provided to the end users. 
The user documentation is designed to assist end users to use the product or service. This is often referred to as user assistance. 
The user documentation is a part of the overall product delivered to the customer. [На основе статей doc-department.com] 

65 Market requirements document, MRD. An MRD goes into details about the target market segments and the issues that 
pertain to commercial success. [«Software Requirements (319 edition)», Karl Wiegers and Joy Beatty] 
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2.2.3. ИСТОЧНИКИ И ПУТИ . 
ВЫЯВЛЕНИЯ ТРЕБОВАНИИ Emm 


Требования начинают свою жизнь на стороне заказчика. Их сбор (gathering) и выявление 
(elicitation) осуществляются с помощью следующих основных техникё66 (рисунок 2.2.4). 


Работа с фокусными 


Интервью 
группами 


Анкетирование 


Семинары и 


р Наблюдение Прототипирование 
мозговой штурм 


Моделирование 
Самостоятельное 


описание 


Анализ документов процессов и 


взаимодействий 


Рисунок 2.2.4 — Основные техники сбора и выявления требований 


Интервью. Самый универсальный путь выявления требований, заключающийся в общении 
проектного специалиста (как правило, специалиста по бизнес-анализу) и представителя заказ- 
чика (или эксперта, пользователя и т.д.) Интервью может проходить в классическом понимании 
этого слова (беседа в виде «вопрос-ответ»), в виде переписки и т.п. Главным здесь является то, 
что ключевыми фигурами выступают двое — интервьюируемый и интервьюер (хотя это и не 
исключает наличия «аудитории слушателей», например, в виде лиц, поставленных в копию пе- 
реписки). 

Работа с фокусными группами. Может выступать как вариант «расширенного интервью», где 
источником информации является не одно лицо, а группа лиц (как правило, представляющих 
собой целевую аудиторию, и/или обладающих важной для проекта информацией, и/или уполно- 
моченных принимать важные для проекта решения). 

Анкетирование. Этот вариант выявления требований вызывает много споров, т. к. при не- 
верной реализации может привести к нулевому результату при объёмных затратах. В то же вре- 
мя при правильной организации анкетирование позволяет автоматически собрать и обработать 
огромное количество ответов от огромного количества респондентов. Ключевым фактором 
успеха является правильное составление анкеты, правильный выбор аудитории и правильное 
преподнесение анкеты. 

Семинары и мозговой штурм. Семинары позволяют группе людей очень быстро обменяться 
информацией (и наглядно продемонстрировать те или иные идеи), а также хорошо сочетаются 


66 Здесь можно почитать подробнее о том, в чём разница между сбором и выявлением требований: «Requirements 
Gathering vs. Elicitation» (Laura Brandenburg): http://www.bridging-the-gap.com/requirements-gathering-vs-elicitation/ 
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с интервью, анкетированием, прототипированием и моделированием — в том числе для обсуж- 
дения результатов и формирования выводов и решений. Мозговой штурм может проводиться 
и как часть семинара, и как отдельный вид деятельности. Он позволяет за минимальное время 
сгенерировать большое количество идей, которые в дальнейшем можно не спеша рассмотреть с 
точки зрения их использования для развития проекта. 

Наблюдение. Может выражаться как в буквальном наблюдении за некими процессами, так и 
во включении проектного специалиста в эти процессы в качестве участника. С одной стороны, 
наблюдение позволяет увидеть то, о чём (по совершенно различным соображениям) могут умол- 
чать интервьюируемые, анкетируемые и представители фокусных групп, нос другой — отнимает 
очень много времени и чаще всего позволяет увидеть лишь часть процессов. 

Прототипирование. Состоит в демонстрации и обсуждении промежуточных версий продук- 
та (например, дизайн страниц сайта может быть сначала представлен в виде картинок, и лишь 
затем свёрстан). Это один из лучших путей поиска единого понимания и уточнения требований, 
однако он может привести к серьёзным дополнительным затратам при отсутствии специаль- 
ных инструментов (позволяющих быстро создавать прототипы) и слишком раннем применении 
(когда требования ещё не стабильны, и высока вероятность создания прототипа, имеющего мало 
общего с тем, что хотел заказчик). 

Анализ документов. Хорошо работает тогда, когда эксперты в предметной области (времен- 
но) недоступны, а также в предметных областях, имеющих общепринятую устоявшуюся регла- 
ментирующую документацию. Также к этой технике относится и просто изучение документов, 
регламентирующих бизнес-процессы в предметной области заказчика или в конкретной орга- 
низации, что позволяет приобрести необходимые для лучшего понимания сути проекта знания. 

Моделирование процессов и взаимодействий. Может применяться как к «бизнес-процессам 
и взаимодействиям» (например: «договор на закупку формируется отделом закупок, визируется 
бухгалтерией и юридическим отделом...»), так и к «техническим процессам и взаимодействи- 
ям» (например: «платёжное поручение генерируется модулем “Бухгалтерия”, шифруется моду- 
лем “Безопасность” и передаётся на сохранение в модуль “Хранилище”»). Данная техника требует 
высокой квалификации специалиста по бизнес-анализу, т.к. сопряжена с обработкой большого 
объёма сложной (и часто плохо структурированной) информации. 

Самостоятельное описание. Является не столько техникой выявления требований, СКОЛЬКО 
техникой их фиксации и формализации. Очень сложно (и даже нельзя!) пытаться самому «при- 
думать требования за заказчика», но в спокойной обстановке можно самостоятельно обработать 
собранную информацию и аккуратно оформить её для дальнейшего обсуждения и уточнения. 


Если вас заинтересовало это направление, стоит ознакомиться со следующими кни- 
гами: 
e «Требования для программного обеспечения: рекомендации по сбору и докумен- 
тированию» (Илья Корнипаев). 
e «Business Analysis Techniques. 72 Essential Tools Юг Success» (James Cadle, Debra Paul, 
Paul Turner). 
e «Business Analysis (Second Edition)» (Debra Paul, Donald Yeates, James Cadle). 


© Часто специалисты по бизнес-анализу приходят в свою профессию из тестирования. 
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2.2.4. УРОВНИ И ТИПЫ ТРЕБОВАНИЙ тиши 


Форма представления, степень детализации и перечень полезных свойств требований зависят 
от уровней и типов требований’, которые схематично представлены на рисунке 2.2.е68. 
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Рисунок 2.2.е — Уровни и типы требований 


Бизнес-требования (business requirements6?) выражают цель, ради которой разрабатывается 
продукт (зачем вообще он нужен, какая от него ожидается польза, как заказчик с его помощью 
будет получать прибыль). Результатом выявления требований на этом уровне является общее 
видение (vision and scope?) — документ, который, как правило, представлен простым текстом 
и таблицами. Здесь нет детализации поведения системы и иных технических характеристик, но 
вполне могут быть определены приоритеты решаемых бизнес-задач, риски и т.п. 

Несколько простых, изолированных от контекста и друг от друга примеров бизнес-требо- 
ваний: 


• Нужен инструмент, в реальном времени отображающий наиболее выгодный курс покупки и 
продажи валюты. 


67 Очень подробное описание уровней и типов требований (а также их применения) можно найти в статье 
«Software Requirements Engineering: What, Why, Who, When, апа Ном», Linda Westfall [http://www.westfallteam.com/ 
Papers/The_Why_What_Who_When_and_How_Of_Software_Requirements.pdf] 

68 B основу данного рисунка положены идеи, представленные в книге «Software Requirements (3rd edition)» (Кай 
Wiegers and Joy Beatty). 

69 Business requirement. Anything that describes the financial, marketplace, or other business benefit that either customers 
or the developing organization wish to gain from the product. [«Software Requirements (3rd edition)», Karl Wiegers and Joy 
Beatty] 

70 Vision and scope. The vision and scope document collects the business requirements into a single deliverable that sets 
the stage for the subsequent development work. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 
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• Необходимо в два-три раза повысить количество заявок, обрабатываемых одним операто- 
ром за смену. 

• Нужно автоматизировать процесс выписки товарно-транспортных накладных на основе 
договоров. 


Пользовательские требования (user гедиігетепіѕ7!) описывают задачи, которые пользователь 
может выполнять с ПОМОЩЬЮ разрабатываемой системы (реакцию системы на действия ПОЛЬЗО- 
вателя, сценарии работы пользователя). Поскольку здесь уже появляется описание поведения 
системы, требования этого уровня могут быть использованы для оценки объёма работ, стоимо- 
сти проекта, времени разработки и т.д. Пользовательские требования оформляются в виде вари- 
антов использования (use са$зе$72), пользовательских историй (user stories’), пользовательских 
сценариев (user ѕсепагіо574). (Также см. создание пользовательских сценариев 48} в процессе вы- 
полнения тестирования.) 


Несколько простых, изолированных от контекста и друг от друга примеров пользовательских 
требований: 


• При первом входе пользователя в систему должно отображаться лицензионное соглашение. 

• Администратор должен иметь возможность просматривать список всех пользователей, pa- 
ботающих в данный момент в системе. 

• При первом сохранении новой статьи система должна выдавать запрос на сохранение в виде 
черновика или публикацию. 


Бизнес-правила (business га]ез”>) описывают особенности принятых в предметной области 
(и/или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут 
относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО ит.д. 


Несколько простых, изолированных от контекста и друг от друга примеров бизнес-правил: 


e Никакой документ, просмотренный посетителями сайта хотя бы один раз, не может быть 
отредактирован или удалён. 

• Публикация статьи возможна только после утверждения главным редактором. 

• Подключение к системе извне офиса запрещено в нерабочее время. 


Атрибуты качества (quality attributes”) расширяют собой нефункциональные требования и 
на уровне пользовательских требований могут быть представлены в виде описания ключевых 
для проекта показателей качества (свойств продукта, не связанных с функциональностью, но яв- 
ляющихся важными для достижения целей создания продукта — производительность, масшта- 


71 User requirement. User requirements аге general statements of user goals ог business tasks that users need to perform. 
[«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 

72 Use case. A sequence of transactions in a dialogue between an actor and a component or system with a tangible result, 
where an actor can be a user or anything that can exchange information with the system. [ISTQB Glossary] 

73 User story. A high-level user or business requirement commonly used in agile software development, typically consisting 
of one or more sentences in the everyday or business language capturing what functionality a user needs, any non-functional 
criteria, and also includes acceptance criteria. [ISTQB Glossary] 

74 A scenario is a hypothetical story, used to help a person think through a complex problem or system. «An Introduction 
to Scenario Testing», Cem Kaner. [http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf] 

75 Business rule. A business rule is a statement that defines or constrains some aspect of the business. It is intended to 
assert business structure or to control or influence the behavior of the business. A business rule expresses specific constraints on 
the creation, updating, and removal of persistent data in an information system. [«Defining Business Rules — What Are They 
Really», David Hay n др.] 

76 Quality attribute. A feature or characteristic that affects an items quality. [ISTQB Glossary] 
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бируемость, восстанавливаемость). Атрибутов качества очень много””, но для любого проекта 
реально важными является лишь некоторое их подмножество. 


Несколько простых, изолированных от контекста и друг от друга примеров атрибутов ка- 
чества: 


• Максимальное время готовности системы к выполнению новой команды после отмены Npe- 
дыдущей не может превышать одну секунду. 

• Внесённые в текст статьи изменения не должны быть утеряны при нарушении соединения 
между клиентом и сервером. 

• Приложение должно поддерживать добавление произвольного количества неиероглифических 
языков интерфейса. 


Функциональные требования (functional requirements”8) описывают поведение системы, 
т.е. её действия (вычисления, преобразования, проверки, обработку и т.д.) В контексте проекти- 
рования функциональные требования в основном влияют на дизайн системы. 


Стоит помнить, что к поведению системы относится не только то, что система должна делать, 
но и то, что она не должна делать (например: «приложение не должно выгружать из оперативной 
памяти фоновые документы в течение 30 минут с момента выполнения с ними последней опера- 
ции»). 


Несколько простых, изолированных от контекста и друг OT друга примеров функциональных 
требований: 


• В процессе инсталляции приложение должно проверять остаток свободного места на целе- 
вом носителе. 

• Система должна автоматически выполнять резервное копирование данных ежедневно в ука- 
занный момент времени. 

• Электронный адрес пользователя, вводимый при регистрации, должен быть проверен на co- 
ответствие требованиям КЕС822. 


Нефункциональные требования (non-functional requirements?) описывают свойства систе- 
мы (удобство использования, безопасность, надёжность, расширяемость и т.д.), которыми она 
должна обладать при реализации своего поведения. Здесь приводится более техническое и де- 
тальное описание атрибутов качества. В контексте проектирования нефункциональные требо- 
вания в основном влияют на архитектуру системы. 


Несколько простых, изолированных от контекста и друг от друга примеров нефункциональ- 
ных требований: 


• При одновременной непрерывной работе с системой 1000 пользователей, минимальное время 
между возникновением сбоев должно быть более или равно 100 часов. 

• Ни при каких условиях общий объём используемой приложением памяти не может превы- 
шать 2 ГБ. 

• Размер шрифта для любой надписи на экране должен поддерживать настройку в диапазоне 
от 5 до 15 пунктов. 


77 Даже в Википедии их список огромен: http://en.wikipedia.org/wiki/List_of_system_quality_attributes 


78 Functional requirement. А requirement that specifies a function that а component ог system must perform. [ISTQB 
Glossary] Functional requirements describe the observable behaviors the system will exhibit under certain conditions and the 
actions the system will let users take. [«Software Requirements (319 edition)», Karl Wiegers and Joy Beatty] 

79 Non-functional requirement. A requirement that does not relate to functionality, but to attributes such as reliability, 
efficiency, usability, maintainability and portability. [ISTQB Glossary] 
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Следующие требования в общем случае могут быть отнесены к нефункциональным, однако 
их часто выделяют в отдельные подгруппы (здесь для простоты рассмотрены лишь три таких 
подгруппы, но их может быть и гораздо больше; как правило, они проистекают из атрибутов ка- 
чества, но высокая степень детализации позволяет отнести их к уровню требований к продукту). 


Ограничения (limitations, сопѕігаіпіѕ80) представляют собой факторы, ограничивающие вы- 
бор способов и средств (в том числе инструментов) реализации продукта. 


Несколько простых, изолированных от контекста и друг от друга примеров ограничений: 


• Все элементы интерфейса должны отображаться без прокрутки при разрешениях экрана 
от 800х600 до 1920х1080. 

• Не допускается использование Flash при реализации клиентской части приложения. 

• Приложение должно сохранять способность реализовывать функции с уровнем важности 
«критический» при отсутствии у клиента поддержки JavaScript. 


Требования к интерфейсам (external interfaces гедиігетепіѕ81) описывают особенности взаи- 
модействия разрабатываемой системы с другими системами и операционной средой. 


Несколько простых, изолированных от контекста и друг от друга примеров требований к ин- 
терфейсам: 


• Обмен данными между клиентской и серверной частями приложения при осуществлении po- 
новых АЈАХ-запросов должен быть реализован в формате JSON. 

• Протоколирование событий должно вестись в журнале событий операционной системы. 

• Соединение с почтовым сервером должно выполняться согласно КЕСЗ207 («SMTP over TLS»). 


Требования к данным (data гедиігетепіѕ82) описывают структуры данных (и сами данные), 
являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание 
базы данных и особенностей её использования. 


Несколько простых, изолированных от контекста и друг от друга примеров требований к 
данным: 


• Все данные системы, за исключением пользовательских документов, должны храниться в БД 
под управлением СУБД MySQL, пользовательские документы должны храниться в БД под 
управлением СУБД MongoDB. 

• Информация о кассовых транзакциях за текущий месяц должна храниться в операционной 
таблице, а по завершении месяца переноситься в архивную. 

• Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены 
полнотекстовые индексы на соответствующих полях таблии. 


Спецификация требований (software requirements specification, 56583) объединяет в себе опи- 
сание всех требований уровня продукта и может представлять собой весьма объёмный документ 
(сотни и тысячи страниц). 


80 Limitation, constraint. Design and implementation constraints legitimately restrict the options available to the developer. 
[«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 

81 Ежегпа! interface requirements. Requirements in this category describe the connections between the system and the rest 
of the universe. They include interfaces to users, hardware, and other software systems. [«Software Requirements (3rd edition)», 
Karl Wiegers and Joy Beatty] 

82 Data requirements. Data requirement describe the format, data type, allowed values, or default value for a data element; 
the composition of a complex business data structure; ог a report to be generated. [«Software Requirements (314 edition)», Karl 
Wiegers and Joy Beatty] 

83 Software requirements specification, SRS. SRS describes as fully as necessary the expected behavior of the software 
system. The SRS is used in development, testing, quality assurance, project management, and related project functions. People 
call this deliverable by many different names, including business requirements document, functional spec, requirements 
document, and others. [«Software Requirements (374 edition)», Karl Wiegers and Joy Beatty] 
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Поскольку требований может быть очень много, а их приходится не только единожды на- 
писать и согласовать между собой, но и постоянно обновлять, работу проектной команды по 
управлению требованиями значительно облегчают соответствующие инструментальные сред- 
ства (requirements management {001584 85). 


2“ Для более глубокого понимания принципов создания, организации и использования 

© набора требований рекомендуется ознакомиться сфундаментальной работой Карла Bn- 

герса «Разработка требований к программному обеспечению» («Software Requirements 

(374 Edition) (Developer Best Practices)», Karl Wiegers, Joy Beatty). В этой же книге (в при- 

ложениях) приведены крайне наглядные учебные примеры документов, описывающих 
требования различного уровня. 


84 Requirements management tool. A tool that supports Фе recording of requirements, requirements attributes (e.g. priority, 
knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change 
management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and 
violations to predefined requirements rules. [ISTQB Glossary] 


85 Обширный список инструментальных средств управления требованиями можно найти здесь: http:// 
makingofsoftware.com/resources/list-of-rm-tools 
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2.2.5. СВОЙСТВА КАЧЕСТВЕННЫХ 
ТРЕБОВАНИИ namm 


В процессе тестирования требований проверяется их соответствие определённому набору 
свойств (рисунок 2.2.1). 


Обязательность | Актуальность 


| Модифицируемость ы \ / Атомарность 


Прослеживаемость 
Корректность и 
проверяемость 
Недвусмысленность 
Выполнимость 


Гл 
| 


Непротиворечивость К 


Завершённость 


Проранжированность | 
Важность | | Стабильность Срочность | 


Рисунок 2.2.f — Свойства качественного требования 


Завершённость (сотр е{епез$86). Требование является полным и законченным с точки зрения 
представления в нём всей необходимой информации, ничто не пропущено по соображениям 


«это и так всем понятно». 
Типичные проблемы с завершённостью: 


e Отсутствуют нефункциональные составляющие требования или ссылки на соответствую- 
щие нефункциональные требования (например: «пароли должны храниться в зашифрован- 
ном виде» — каков алгоритм шифрования?). 

e Указана лишь часть некоторого перечисления (например: «экспорт осуществляется в pop- 
маты PDF, PNG и т.д.» — что мы должны понимать под «и т.д.»?). 

• Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.6»). 


86 Each requirement must contain all the information necessary for the reader to understand it. In the case of functional 
requirements, this means providing the information the developer needs to be able to implement it correctly. No requirement or 
necessary information should be absent. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 
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Атомарность, единичность (atomicity87). Требование является атомарным, если его нельзя 
разбить на отдельные требования без потери завершённости и оно описывает одну и только одну 
ситуацию. 


Типичные проблемы с атомарностью: 


• В одном требовании, фактически, содержится несколько независимых (например: «кнопка 
“Restar?” не должна отображаться при остановленном сервисе, окно “Го” должно вмещать 
не менее 20-ти записей о последних действиях пользователя» — здесь зачем-то в одном 
предложении описаны совершенно разные элементы интерфейса в совершенно разных кон- 
текстах). 

• Требование допускает разночтение в силу грамматических особенностей языка (например: 
«если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, дол- 
жен выдаваться запрос на оплату» — здесь описаны три разных случая, и это требование 
стоит разбить на три отдельных во избежание путаницы). Такое нарушение атомарности 
часто влечёт за собой возникновение противоречивости. 

• В одном требовании объединено описание нескольких независимых ситуаций (например: 
«когда пользователь входит в систему, ему должно отображаться приветствие; когда поль- 
зователь вошёл в систему, должно отображаться имя пользователя; когда пользователь вы- 
ходит из системы, должно отображаться прощание» — все эти три ситуации заслуживают 
того, чтобы быть описанными отдельными и куда более детальными требованиями). 


Непротиворечивость, последовательность (сопѕіѕіепсу88). Требование не должно содержать 
внутренних противоречий и противоречий другим требованиям и документам. 


Типичные проблемы с непротиворечивостью: 


e Противоречия внутри одного требования (например: «после успешного входа в систему 
пользователя, не имеющего права входить в систему...» — тогда как он успешно вошёл в 
систему, если не имел такого права?) 

e Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком 
и текстом, требованием и прототипом и т.д. (например: «712.а Кнопка “Close” всегда должна 
быть красной» и «36452.х Кнопка “Close” всегда должна быть синей» — так всё же красной 
или синей?) 

• Использование неверной терминологии или использование разных терминов для обозна- 
чения одного и того же объекта или явления (например: «в случае, если разрешение окна 
составляет менее 800х600...» — разрешение есть у экрана, у окна есть размер). 


Недвусмысленность (unambiguousness3’, clearness). Требование описано без использования 
жаргона, неочевидных аббревиатур и расплывчатых формулировок и допускает только одно- 
значное объективное понимание. Требование атомарно в плане невозможности различной трак- 
товки сочетания отдельных фраз. 


87 Fach requirement you write represents а single market need that you either satisfy ог fail to satisfy. А well written 
requirement is independently deliverable and represents an incremental increase in the value of your software. [«Writing Good 
Requirements — The Big Ten Rules», Tyner Blain: http://tynerblain.com/blog/2006/05/25/writing-good-requirements-the-big- 
ten-rules/] 

88 Consistent requirements dort conflict with other requirements of the same type or with higher-level business, user, or 
system requirements. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 

89 Natural language is prone to two types of ambiguity. One type I can spot myself, when I can think of more than one way to 
interpret a given requirement. The other type of ambiguity is harder to catch. That’s when different people read the requirement 
and соте up with different interpretations of it. [«Software Requirements (3:4 edition)», Karl Wiegers and Joy Beatty] 
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Типичные проблемы с недвусмысленностью: 


e Использование терминов или фраз, допускающих субъективное толкование (например: 
«приложение должно поддерживать передачу больших объёмов данных» — насколько «боль- 
ших»?) Вот лишь небольшой перечень слов и выражений, которые можно считать верны- 
ми признаками двусмысленности: адекватно (adequate), быть способным (be able to), легко 
(easy), обеспечивать (provide Юг), как минимум (аз а minimum), быть способным (be ca- 
pable of), эффективно (effectively), своевременно (timely), применимо (as applicable), если воз- 
можно (if possible), будет определено позже (to be determined, TBD), по мере необходимости 
(аз appropriate), если это целесообразно (if practical), но не ограничиваясь (but not limited to), 
быть способно (capability of), иметь возможность (capability to), нормально (normal), mn- 
нимизировать (minimize), максимизировать (maximize), оптимизировать (optimize), быстро 
(rapid), удобно (user-friendly), просто (simple), часто (often), обычно (usual), большой (large), 
гибкий (flexible), устойчивый (robust), по последнему слову техники (state-of-the-art), улуч- 
шенный (improved), результативно (efficient). Вот утрированный пример требования, зву- 
чащего очень красиво, но совершенно нереализуемого и непонятного: «В случае необходи- 
мости оптимизации передачи больших файлов система должна эффективно использовать 
минимум оперативной памяти, если это возможно». 

• Использование неочевидных или двусмысленных аббревиатур без расшифровки (например: 
«доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС пре- 
доставляет возможность фиксировать сообщения в их текущем состоянии с хранением 
истории всех изменений» — ФС здесь обозначает файловую систему? Точно? А не какой-ни- 
будь «Фиксатор Сообщений»?) 

e Формулировка требований из соображений, что нечто должно быть всем очевидно (на- 
пример: «Система конвертирует входной файл из формата РПЕ в выходной файл форма- 
та PNG» — и при этом автор считает совершенно очевидным, что имена файлов систе- 
ма получает из командной строки, а многостраничный PDF конвертируется в несколько 
РМС-файлов, к именам которых добавляется «разе-1», «page-2» и т.д.). Эта проблема пе- 
рекликается с нарушением корректности. 


Выполнимость (feasibility’0). Требование технологически выполнимо и может быть реализо- 
вано в рамках бюджета и сроков разработки проекта. 


Типичные проблемы C ВЫПОЛНИМОСТЬЮ: 


e Так называемое «озолочение» (gold plating) — требования, которые крайне долго и/или до- 
рого реализуются и при этом практически бесполезны для конечных пользователей (напри- 
мер: «настройка параметров для подключения к базе данных должна поддерживать распо- 
знавание символов из жестов, полученных с устройств трёхмерного ввода»). 

• Технически нереализуемые на современном уровне развития технологий требования (на- 
пример: «анализ договоров должен выполняться с применением искусственного интеллекта, 
который будет выносить однозначное корректное заключение о степени выгоды от заклю- 
чения договора»). 

• В принципе нереализуемые требования (например: «система поиска должна заранее преду- 
сматривать все возможные варианты поисковых запросов и кэшировать их результаты»). 


90 It must Бе possible to implement each requirement within the known capabilities and limitations of the system and its 
operating environment, as well as within project constraints of time, budget, and staff. [«Software Requirements (3rd edition)», 
Karl Wiegers and Joy Beatty] 
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Обязательность, нужность (оЬраїогїпе$5?!) и актуальность (up-to-date). Если требование не 
является обязательным к реализации, оно должно быть просто исключено из набора требова- 
ний. Если требование нужное, но «не очень важное», для указания этого факта используется 
указание приоритета (см. «проранжированность по...»). Также исключены (или переработаны) 
должны быть требования, утратившие актуальность. 


Типичные проблемы с обязательностью и актуальностью: 


• Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было 
и нет. 

e Требованию выставлены неверные значения приоритета по критериям важности и/или 
срочности. 

• Требование устарело, но не было переработано или удалено. 


Прослеживаемость (їтасеаыШїу?293). Прослеживаемость бывает вертикальной (vertical 
{тасеаЫШу?#) и горизонтальной (horizontal traceability?5). Вертикальная позволяет соотносить 
между собой требования на различных уровнях требований, горизонтальная позволяет соотно- 
сить требование с тест-планом, тест-кейсами, архитектурными решениями ит.д. 

Для обеспечения прослеживаемости часто используются специальные инструменты по 
управлению требованиями (requirements management 100196) и/или матрицы прослеживаемости 
(traceability matrix?”). 


Типичные проблемы с прослеживаемостью: 


• Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют pabo- 
тающих перекрёстных ссылок. 

e При разработке требований не были использованы инструменты и техники управления тре- 
бованиями. 


• Набор требований неполный, носит обрывочный характер с явными «пробелами». 


91 Each requirement should describe а capability that provides stakeholders with the anticipated business value, differentiates 
the product in the marketplace, or is required for conformance to an external standard, policy, or regulation. Every requirement 
should originate from a source that has the authority to provide requirements. [«Software Re-quirements (314 edition)», Karl 
Wiegers and Joy Beatty] 

92 Traceability. The ability to identify related items in documentation and software, such as requirements with associated 
tests. [ISTQB Glossary] 

93 А traceable requirement can Бе linked both backward to its origin and forward to derived requirements, design elements, 
code that implements it, and tests that verify its implementation. [«Software Requirements (3:4 edition)», Karl Wiegers and Joy 
Beatty] 

94 Vertical traceability. The tracing of requirements through the layers of development documentation to components. 
[ISTQB Glossary] 

95 Horizontal traceability. The tracing of requirements for a test level through the layers of test documentation (e.g. test 
plan, test design specification, test case specification and test procedure specification or test script). [ISTQB Glossary] 

96 Requirements management tool. A tool that supports the recording of requirements, requirements attributes (e.g. priority, 
knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change 
management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and 
violations to predefined requirements rules. [ISTQB Glossary] 

97 Traceability matrix. A two-dimensional table, which correlates two entities (e.g., requirements and test cases). The table 
allows tracing back and forth the links of one entity to the other, thus enabling the determination of coverage achieved and the 
assessment of impact of proposed changes. [ISTQB Glossary] 
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Модифицируемость (modifiability?$). Это свойство характеризует простоту внесения измене- 
ний в отдельные требования и в набор требований. Можно говорить о наличии модифициру- 
емости в том случае, если при доработке требований искомую информацию легко найти, а её 
изменение не приводит к нарушению иных описанных в этом перечне свойств. 


Типичные проблемы с модифицируемостью: 


• Требования неатомарны (см. «атомарность») и непрослеживаемы (см. «прослеживаемость»), 
а потому их изменение с высокой вероятностью порождает противоречивость (см. «непро- 
тиворечивость»). 

• Требования изначально противоречивы (см. «непротиворечивость»). В такой ситуации вне- 
сение изменений (не связанных с устранением противоречивости) только усугубляет ситуа- 
цию, увеличивая противоречивость и снижая прослеживаемость. 

e Требования представлены в неудобной для обработки форме (например, не использованы 
инструменты управления требованиями, и в итоге команде приходится работать с десятка- 
ми огромных текстовых документов). 


Проранжированность по важности, стабильности, срочности (ranked?? {ог importance, 
stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации тре- 
бования. Стабильность характеризует вероятность того, что в обозримом будущем в требование 
не будет внесено никаких изменений. Срочность определяет распределение во времени усилий 
проектной команды по реализации того или иного требования. 


Типичные проблемы с проранжированностью состоят в её отсутствии или неверной реализа- 
ции и приводят к следующим последствиям. 


• Проблемы с проранжированностью по важности повышают риск неверного распределения 
усилий проектной команды, направления усилий на второстепенные задачи и конечного 
провала проекта из-за неспособности продукта выполнять ключевые задачи с соблюдением 
ключевых условий. 

• Проблемы с проранжированностью по стабильности повышают риск выполнения бессмыс- 
ленной работы по совершенствованию, реализации и тестированию требований, которые 
в самое ближайшее время могут претерпеть кардинальные изменения (вплоть до полной 
утраты актуальности). 

• Проблемы с проранжированностью по срочности повышают риск нарушения желаемой 3a- 
казчиком последовательности реализации функциональности и ввода этой функциональ- 
ности в эксплуатацию. 


Корректность (соггесіпеѕѕ100) и проверяемость (уемва Ш ку!01). Фактически эти свойства вы- 
текают из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, 


98 То facilitate modifiability, avoid stating requirements redundantly. Repeating а requirement іп multiple places where it 
logically belongs makes the document easier to read but harder to maintain. The multiple instances of the require-ment all have 
to be modified at the same time to avoid generating inconsistencies. Cross-reference related items in the SRS to help keep them 
synchronized when making changes. [«Software Requirements (374 edition)», Karl Wieg-ers and Joy Beatty] 

99 Prioritize business requirements according to which are most important to achieving the desired value. Assign an 
implementation priority to each functional requirement, user requirement, use case flow, or feature to indicate how essential it 
is to a particular product release. [«Software Requirements (374 edition)», Karl Wiegers and Joy Beatty] 

100 Each requirement must accurately describe a capability that will meet some stakeholder’s need and must clearly describe 
the functionality to be built. [«Software Requirements (319 edition)», Karl Wiegers and Joy Beatty] 

101 Ша requirement 150% verifiable, deciding whether it was correctly implemented becomes a matter of opinion, not 
objective analysis. Requirements that are incomplete, inconsistent, infeasible, or ambiguous are also unverifiable. [«Software 
Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 
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если нарушено хотя бы ОДНО ИЗ вышеперечисленных). В дополнение можно отметить, что про- 
веряемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), одно- 
значно показывающего, что требование реализовано верно и поведение приложения в точности 
соответствует требованию. 


К типичным проблемам с корректностью также можно отнести: 


e опечатки (особенно опасны опечатки в аббревиатурах, превращающие одну осмысленную 
аббревиатуру в другую также осмысленную, но не имеющую отношения к некоему контек- 
сту; такие опечатки крайне сложно заметить); 

• наличие неаргументированных требований к дизайну и архитектуре; 

• плохое оформление текста и сопутствующей графической информации, грамматические, 
пунктуационные и иные ошибки в тексте; 

• неверный уровень детализации (например, слишком глубокая детализация требования на 
уровне бизнес-требований или недостаточная детализация на уровне требований к про- 
дукту); 

• требования к пользователю, а не к приложению (например: «пользователь должен быть в 
состоянии отправить сообщение» — увы, мы не можем влиять на состояние пользователя). 


Ў \ Хорошее краткое руководство по написанию качественных требований представлено в 
статье «Writing Good Requirements — The Big Ten Виез»102. 


102 «Writing Good Requirements — The Big Ten Rules», Tyner Blain [http://tynerblain.com/blog/2006/05/25/writing- 
good-requirements-the-big-ten-rules/] 
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2.2.6. ТЕХНИКИ ТЕСТИРОВАНИЯ 
ТРЕБОВАНИИ namm 


Тестирование документации и требований относится к разряду нефункционального тестиро- 
вания (non-functional testing103). Основные техники такого тестирования в контексте требова- 
ний таковы. 


Взаимный просмотр (peer review!?4). Взаимный просмотр («рецензирование») является од- 
ной из наиболее активно используемых техник тестирования требований и может быть пред- 
ставлен в одной из трёх следующих форм (по мере нарастания его сложности и цены): 


e Беглый просмотр (walkthrough!05) может выражаться как в показе автором своей работы 
коллегам с целью создания общего понимания и получения обратной связи, так и в простом 
обмене результатами работы между двумя и более авторами с тем, чтобы коллега высказал 
свои вопросы и замечания. Это самый быстрый, самый дешёвый и наиболее широко исполь- 
зуемый вид просмотра. 

Для запоминания: аналог беглого просмотра — это ситуация, когда вы в школе с однокласс- 
никами проверяли перед сдачей сочинения друг друга, чтобы найти описки и ошибки. 

• Технический просмотр (technical геуїеу/10б) выполняется группой специалистов. В идеаль- 
ной ситуации каждый специалист должен представлять свою область знаний. Тестируемый 
продукт не может считаться достаточно качественным, пока хотя бы у одного просматри- 
вающего остаются замечания. 

Для запоминания: аналог технического просмотра — это ситуация, когда некий договор ви- 
зирует юридический отдел, бухгалтерия ит.д. 

• Формальная инспекция (іпѕресііоп!07) представляет собой структурированный, система- 
тизированный и документируемый подход к анализу документации. Для его выполнения 
привлекается большое количество специалистов, само выполнение занимает достаточно 
много времени, и потому этот вариант просмотра используется достаточно редко (как пра- 
вило, при получении на сопровождение и доработку проекта, созданием которого ранее за- 
нималась другая компания). 

Для запоминания: аналог формальной инспекции — это ситуация генеральной уборки квар- 
тиры (включая содержимое всех шкафов, холодильника, кладовки и т.д.) 


Вопросы. Следующей очевидной техникой тестирования и повышения качества требований 
является (повторное) использование техник выявления требований, а также (как отдельный вид 
деятельности) — задавание вопросов. Если хоть что-то в требованиях вызывает у вас непонима- 
ние или подозрение — задавайте вопросы. Можно спросить представителей заказчика, можно 
обратиться к справочной информации. По многим вопросам можно обратиться к более опыт- 
ным коллегам при условии, что у них имеется соответствующая информация, ранее полученная 


103 Non-functional testing. Testing the attributes of a component ог system that do not relate to functionality, e.g. reliability, 
efficiency, usability, maintainability and portability. [ISTQB Glossary] 

104 Peer review. A review of a software work product by colleagues of the producer of the product for the purpose of 
identifying defects and improvements. Examples are inspection, technical review and walkthrough. [ISTQB Glossary] 

105 Walkthrough. A step-by-step presentation by the author of a document in order to gather information and to establish 
a common understanding of its content. [ISTQB Glossary] 

106 Technical review. A peer group discussion activity that focuses on achieving consensus on the technical approach to be 
taken. [ISTQB Glossary] 

107 Inspection. A type of peer review that relies on visual examination of documents to detect defects, e.g. violations of 
development standards and non-conformance to higher level documentation. The most formal review technique and therefore 
always based on a documented procedure. [ISTQB Glossary] 
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от заказчика. Главное, чтобы ваш вопрос был сформулирован таким образом, чтобы полученный 
ответ позволил улучшить требования. 

Поскольку здесь начинающие тестировщики допускают уйму ошибок, рассмотрим подробнее. 
В таблице 2.2.а приведено несколько плохо сформулированных требований, а также примеров 
плохих и хороших вопросов. Плохие вопросы провоцируют на бездумные ответы, не содержа- 
щие полезной информации. 


Таблица 2.2.а — Пример плохих и хороших вопросов к требованиям 


Плохое требование 


Плохие вопросы 


Хорошие вопросы 


«Приложение должно 
быстро запускаться». 


«Насколько быстро?» (На это вы 
рискуете получить ответы в стиле 
«очень быстро», «максимально бы- 
стро», «нууу... просто быстро»). 
«А если не получится быстро?» 
(Этим вы рискуете просто удивить 
или даже разозлить заказчика.) 
«Всегда?» («Да, всегда». Хм, а вы 
ожидали другого ответа?) 


«Каково максимально допустимое 
время запуска приложения, на ка- 
ком оборудовании и при какой за- 
груженности этого оборудования 
операционной системой и другими 
приложениями? На достижение 
каких целей влияет скорость запу- 
ска приложения? Допускается ли 
фоновая загрузка отдельных ком- 
понентов приложения? Что явля- 
ется критерием того, что приложе- 
ние закончило запуск?» 


«Опционально дол- 
жен поддерживаться 
экспорт документов в 
формат PDF». 


«Любых документов?» (Ответы 
«да, любых» или «нет, только от- 
крытых» вам всё равно не помо- 
гут.) 

«В PDF какой версии должен npo- 
изводиться экспорт?» (Сам по себе 
вопрос хорош, но он не даёт по- 
нять, что имелось в виду под «оп- 
ционально».) 

«Зачем?» («Нужно!» Именно так 
хочется ответить, если вопрос не 
раскрыт полностью.) 


«Насколько возможность экспор- 
та в PDF важна? Как часто, кем и 
с какой целью она будет исполь- 
зоваться? Является ли PDF един- 
ственным допустимым форматом 
для этих целей или есть альтерна- 
тивы? Допускается ли использо- 
вание внешних утилит (например, 
виртуальных РОЕ-принтеров) для 
экспорта документов в PDF?» 


«Если дата события не 
указана, она выбирает- 
ся автоматически». 


«А если указана?» (То она указана. 
Логично, не так ли?) 

«А если дату невозможно выбрать 
автоматически» (Сам вопрос ин- 
тересен, но без пояснения причин 
невозможности звучит как из- 
дёвка.) 

«А если у события нет даты?» (Тут 
автор вопроса, скорее всего, хотел 
уточнить, обязательно ли это поле 
для заполнения. Но из самого тре- 
бования видно, что обязательно: 
если оно не заполнено человеком, 
его должен заполнить компьютер.) 


«Возможно, имелось в виду, что 
дата генерируется автоматически, 
ане выбирается? Если да, то по ка- 
кому алгоритму она генерируется? 
Если нет, то из какого набора вы- 
бирается дата и как генерируется 
этот набор? P.S. Возможно, стоит 
использовать текущую дату?» 
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Тест-кейсы и чек-листы. Мы помним, что хорошее требование является проверяемым, а зна- 
чит, должны существовать объективные способы определения того, верно ли реализовано тре- 
бование. Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа тре- 
бований позволяет нам определить, насколько требование проверяемо. Если вы можете быстро 
придумать несколько пунктов чек-листа, это ещё не признак того, что с требованием всё хорошо 
(например, оно может противоречить каким-то другим требованиям). Но если никаких идей по 
тестированию требования в голову не приходит — это тревожный знак. 

Рекомендуется для начала убедиться, что вы понимаете требование (в том числе прочесть со- 
седние требования, задать вопросы коллегам и т.д.) Также можно пока отложить работу с дан- 
ным конкретным требованием и вернуться к нему позднее — возможно, анализ других требо- 
ваний позволит вам лучше понять и это конкретное. Но если ничто не помогает — скорее всего, 
с требованием что-то не так. 

Справедливости ради надо отметить, что на начальном этапе проработки требований такие 
случаи встречаются очень часто — требования сформированы очень поверхностно, расплыв- 
чато и явно нуждаются в доработке, т.е. здесь нет необходимости проводить сложный анализ, 
чтобы констатировать непроверяемость требования. 

На стадии же, когда требования уже хорошо сформулированы и протестированы, вы можете 
продолжать использовать эту технику, совмещая разработку тест-кейсов и дополнительное тес- 
тирование требований. 


Исследование поведения системы. Эта техника логически вытекает из предыдущей (проду- 
мывания тест-кейсов и чек-листов), но отличается тем, что здесь тестированию подвергается, 
как правило, не одно требование, а целый набор. Тестировщик мысленно моделирует процесс ра- 
боты пользователя с системой, созданной по тестируемым требованиям, и ищет неоднозначные 
или вовсе неописанные варианты поведения системы. Этот подход сложен, требует достаточной 
квалификации тестировщика, но способен выявить нетривиальные недоработки, которые почти 
невозможно заметить, тестируя требования по отдельности. 


Рисунки (графическое представление). Чтобы увидеть общую картину требований целиком, 
очень удобно использовать рисунки, схемы, диаграммы, интеллект-карты!0 и т.д. Графическое 
представление удобно одновременно своей наглядностью и краткостью (например, ОМІ-схема 
базы данных, занимающая один экран, может быть описана несколькими десятками страниц 
текста). На рисунке очень легко заметить, что какие-то элементы «не стыкуются», что где-то че- 
го-то не хватает и т.д. Если вы для графического представления требований будете использо- 
вать общепринятую нотацию (например, уже упомянутый UML), вы получите дополнительные 
преимущества: вашу схему смогут без труда понимать и дорабатывать коллеги, а в итоге может 
получиться хорошее дополнение к текстовой форме представления требований. 


Прототипирование. Можно сказать, что прототипирование часто является следствием созда- 
ния графического представления и анализа поведения системы. С использованием специальных 
инструментов можно очень быстро сделать наброски пользовательских интерфейсов, оценить 
применимость тех или иных решений и даже создать не просто «прототип ради прототипа», а за- 
готовку для дальнейшей разработки, если окажется, что реализованное в прототипе (возможно, 
с небольшими доработками) устраивает заказчика. 


108 «Mind тар» [http://en.wikipedia.org/wiki/Mind_map] 
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2.2.7. ПРИМЕР АНАЛИЗА . 
И ТЕСТИРОВАНИЯ ТРЕБОВАНИИ ишкиш 


Поскольку наша задача состоит в том, чтобы сформировать понимание логики анализа и тес- 
тирования требований, мы будем рассматривать предельно краткий и простой их набор. 


ге Карла Вигерса «Разработка требований к программному обеспечению» («Software 


© Отличный подробный пример требований можно найти в приложениях к кни- 
Requirements (3rd Edition) (Developer Best Practices)», Karl Wiegers, Joy Beatty). 


Допустим, что у некоего клиента есть проблема: поступающие в огромном количестве его CO- 
трудникам текстовые файлы приходят в разных кодировках, и сотрудники тратят много времени 
на перекодирование («ручной подбор кодировки»). Соответственно, он хотел бы иметь инстру- 
мент, позволяющий автоматически приводить кодировки всех текстовых файлов к некоей од- 
ной. Итак, на свет появляется проект с кодовым названием «Конвертер файлов». 


Уровень бизнес-требований. Бизнес-требования (см. главу «Уровни и типы требований») 
изначально могут выглядеть так: «Необходим инструмент для автоматического приведения ко- 
дировок текстовых документов K одной». 

Здесь мы можем задать множество вопросов. Для удобства приведём как сами вопросы, так и 
предполагаемые ответы клиента. 


Задание 2.2.Ъ: прежде чем читать приведённый ниже список вопросов, сформулируйте 
собственный. 


e В каких форматах представлены текстовые документы (обычный текст, HTML, МР, что-то 
иное)? (Понятия не имею, я в этом не разбираюсь.) 

• В каких кодировках приходят исходные документы? (В разных.) 

• В какую кодировку нужно преобразовать документы? (В самую удобную и универсальную.) 

• На каких языках написан текст в документах? (Русский и английский.) 

e Откуда и как поступают текстовые документы (по почте, с сайтов, по сети, как-то иначе)? 
(Это неважно. Поступают отовсюду, но мы их складываем в одну папку на диске, нам так 
удобно.) 

• Каков максимальный объём документа? (Пара десятков страниц.) 

• Как часто появляются новые документы (например, сколько максимум документов может 
поступить за час)? (200-300 в час.) 

e С помощью чего сотрудники просматривают документы? (№оѓерай++.) 


Даже таких вопросов и ответов достаточно, чтобы переформулировать бизнес-требования 
следующим образом (обратите внимание, что многие вопросы были заданы на будущее и не при- 
вели к появлению в бизнес-требованиях лишней технической детализации). 


Суть проекта: разработка инструмента, устраняющего проблему множественности кодиро- 
вок в текстовых документах, расположенных в локальном дисковом хранилище. 


Цели проекта: 


• Исключение необходимости ручного подбора кодировок текстовых документов. 
е Сокращение времени работы с текстовым документом на величину, необходимую ДЛЯ руч- 
ного подбора кодировки. 
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Метрики достижения целей: 


• Полная автоматизация определения и преобразования кодировки текстового документа к 
заданной. 

e Сокращение времени обработки текстового документа в среднем на 1-2 минуты на доку- 
мент за счёт устранения необходимости ручного подбора кодировки. 


Риски: 


e Высокая техническая сложность безошибочного определения исходной кодировки тексто- 
вого документа. 


Почему мы решили, что среднее время на подбор кодировки составляет 1-2 минуты? Мы про- 
вели наблюдение. Также мы помним ответы заказчика на вопросы об исходных форматах доку- 
ментов, исходных и конечной кодировках (заказчик честно сказал, что не знает ответа), а потому 
мы попросили его предоставить нам доступ к хранилищу документов и выяснили: 


• Исходные форматы: plain text, HTML, MD. 
» Исходные кодировки: CP1251, UTF8, СР866, КО18К. 
• Целевая кодировка: UTF8. 


На данном этапе мы вполне можем решить, что стоит заняться детализацией требований на 
более низких уровнях, т.к. появившиеся там вопросы позволят нам вернуться к бизнес-требова- 
ниям и улучшить их, если в этом возникнет необходимость. 


Уровень пользовательских требований. Пришло время заняться уровнем пользовательских 
требований (см. главу «Уровни и типы требований» (39). Проект у нас несколько специфичный — 
результатами работы программного средства будет пользоваться большое количество людей, но 
само программное средство при этом они использовать не будут (оно будет просто выполнять 
свою работу «само по себе» — запущенное на сервере с хранилищем документов). Потому под 
пользователем здесь мы будем понимать человека, настраивающего работу приложения на сер- 
вере. 


Для начала мы создадим небольшую диаграмму вариантов использования, представленную 
на рисунке 2.2.5 (да, иногда её создают после текстового описания требований, но иногда и до — 
нам сейчас удобнее сделать это сначала). В реальных проектах подобные схемы могут быть на 
несколько порядков более сложными и требующими подробной детализации каждого варианта 
использования. У нас же проект миниатюрный, потому схема получилась элементарной, и мы 
сразу переходим к описанию требований. 


Внимание! Это — ПЛОХИЕ требования. И мы далее будем их улучшать. 


Системные характеристики 

» СХ-1: Приложение является консольным. 

• СХ-2: Для работы приложение использует интерпретатор РНР. 
e СХ-3: Приложение является кроссплатформенным. 
Пользовательские требования 

• Также см. диаграмму вариантов использования. 

• ПТ-1: Запуск и остановка приложения. 


° ПТ-1.1: Запуск приложения производится из консоли командой «РНР converter.php па- 
раметры». 


° ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C. 
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Приложение 


Остальные функции реализуются 
иными средствами и не 
предоставляются 
разрабатываемым приложением 


Конфигурирование 
приложения 


Администратор 


Запуск приложения 


Остановка 
приложения 


Просмотр журнала 
работы приложения 


Рисунок 2.2.5 — Диаграмма вариантов использования 


• ПТ-2: Конфигурирование приложения. 


° ПТ-2.1: Конфигурирование приложения сводится к указанию путей в файловой cn- 
стеме. 
о ПТ-2.2: Целевой кодировкой является ОТЕ8. 
• ПТ-3: Просмотр журнала работы приложения. 
e ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в KOH- 
соль и лог-файл. 


° ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при последующих — до- 
писывается. 


Бизнес-правила 
e БП-1: Источник и приёмник файлов 


о БП-1.1: Каталоги, являющиеся источником исходных и приёмником конечных файлов 
не должны совпадать. 

e БП-1.2: Каталог, являющийся приёмником конечных файлов, не может быть подката- 
логом источника. 
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Системные характеристики Author 
* CX-1: Приложение является консольным ŤCñĚ 1) Какая минимальная версия интерпретатора РНР 
• СХ-2: Для работы приложение использует интерпретатор РНЕ |222 w лс кт r 


ieee AE e ые daaa ``“, 2) Существует ли некая специфика настройки 


e СХ-3: Приложение является кроссплатформеннымі интерпретатора РНР для корректной работы 


Пользовательские требования y b A Author 
• Также см. диаграмму вариантов использования. ` ` Должна ли в руководстве пользователя быть 
• ПТ-1: Запуск и остановка приложения. ` ` описана пропедура установки и настройки 


i 
o ПТ-1.1: Запуск приложения производится из консоли командой “PHDhp _ а 
converter.php параметры. ^, \ f| Author 
© ПТ-1.2: Остановка приложения производится выполнением команды `, `| Formatted: Russian 
Сіп+С в окне консоли, из которого было запущено приложение. `‘ Author 
* ПТ-2: Конфигурирование приложения. | Какие ОС должны поддерживаться? В чём цель 
© ПТ-2.1: Конфигурирование приложения сводится к указанию путей в | кросспла: ? 
файловой системе __ осо о Author 
о ПТ-2.2: Целевой кодировкой является ИТЕ8 A Какие параметры передаются скрипту при 
• ПТ-3: Просмотр журнала работы приложения. лл =з мазу вена станаа 
о ПТ-3.1: В процессе работы приложение должно Выводить журнал своей `` ` зен, петно АВ 


работы в консоль и лог-файдф 
о ПТ-3.2: При первом запуске приложения лог-файл создаётся, а При \` `` 
последующих — дописывается| i ] ишн 


Путей к чему? 


* Неверные значения каждого из параметров. 


Рисунок 2.2.h — Использование средств Word для работы с требованиями 


Атрибуты качества 
e АК-1: Производительность 

° АК-1.1: Приложение должно обеспечивать скорость обработки данных 5 МБ/сек. 
e АК-2: Устойчивость к входным данным 


° АК-2.1: Приложение должно обрабатывать входные файлы размером до 50 МБ вклю- 
чительно. 

° АК-2.2: Если входной файл не является текстовым, приложение должно произвести об- 
работку. 


Как будет сказано в главе «Типичные ошибки при анализе и тестировании требований» {62}, 
не стоит изменять исходный формат файла и форматирование документа, потому мы использу- 
ем встроенные средства Word для отслеживания изменений и добавления комментариев. При- 
мерный вид результата показан на рисунке 2.2.6. 

К сожалению, мы не можем в данном тексте применить эти средства (результат будет отобра- 
жаться некорректно, т.к. вы сейчас, скорее всего, читаете этот текст не в виде ООСХ-документа), 
а потому применим второй классический способ — будем вписывать свои вопросы и коммента- 
рии прямо внутрь текста требований. 

Проблемные места требований отмечены подчёркиванием, наши вопросы отмечены курси- 
вом, предполагаемые ответы заказчика (даже, если точнее, технического специалиста заказчи- 
ка) — жирным. В процессе анализа текст требований примет вот такой вид. 


Задание 2.2.с: проанализируйте предложенный набор требований с точки зрения 
свойств качественных требований 4}, сформулируйте свои вопросы заказчику, кото- 
рые позволят улучшить этот набор требований. 


Системные характеристики 
» СХ-1: Приложение является консольным. 
e СХ-2: Для работы приложение использует интерпретатор РНР. 


° Какая минимальная версия интерпретатора РНР поддерживается приложением? (5.5.х) 
° Существует ли некая специфика настройки интерпретатора РНР для корректной ра- 
боты приложения? (Наверное, должен работать mbstring.) 
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° Настаиваете ли вы на реализации приложения именно на РНР? Если да, то почему. 
(Да, только PHP. У нас есть сотрудник, который его знает.) 

° Должна ли в руководстве пользователя быть описана процедура установки и настрой- 
ки интерпретатора РНР? (Нет.) 


e СХ-3: Приложение является кроссплатформенным. 


° Какие ОС должны поддерживаться? (Любая, где работает РНР.) 
° В чём вообще цель кроссилатформенности? (Мы ещё не знаем, на чём будет работать 
сервер.) 
Пользовательские требования 
e Также см. диаграмму вариантов использования. 
• ПТ-1: Запуск и остановка приложения. 
° ПТ-1.1: Запуск приложения производится из консоли командой «РНР (возможно, здесь 
опечатка: должно быть php (в нижнем регистре)) (Да, ОК.) сопуецег.рЬр параметры». 


" Какие параметры передаются скрипту при запуске? (Каталог с исходными фай- 
лами, каталог с конечными файлами.) 
a Какова реакция скрипта на: 
+ отсутствие параметров; (Пишет хелп.) 
• неверное количество параметров; (Пишет хелп и поясняет, что не так.) 
• неверные значения каждого из параметров. (Пишет хелп и поясняет, что 
не так.) 
° ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C (предлага- 
ем дополнить это выражение фразой «в окне консоли, из которого было запущено при- 
ложение») (Да, ОК.). 


• ПТ-2: Конфигурирование приложения. 


° ПТ-2.1: Конфигурирование приложения сводится к указанию путей в файловой cn- 
стеме. 


„ Путей к чему? (Каталог с исходными файлами, каталог с конечными файлами.) 


e ПТ-2.2: Целевой кодировкой является UTF8. 


= Предполагается ли указание иной целевой кодировки, или UTF8 используется в Ka- 
честве целевой всегда? (Только ОТЕ8, других не надо.) 


• ПТ-3: Просмотр журнала работы приложения. 


° ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в кон- 
соль и лог-файл. 


" Каков формат журнала? (Дата-время, что и с чем делали, что получилось. Глянь- 
те в логе апача, там нормально написано.) 

" Различаются ли форматы журнала для консоли и лог-файла? (Нет.) 

" Как определяется имя лог-файла? (Третий параметр при запуске. Если не ука- 
зан — пусть будет converter.log рядом с рћр-скриптом.) 


° ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при последующих — 
дописывается. 
a Как приложение различает свой первый и последующие запуски? (Никак.) 
= Какова реакция приложения на отсутствие лог-файла в случае, если это не первый 
запуск? (Создаёт. Тут идея в том, чтобы оно не затирало старый лог — и всё.) 
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Бизнес-правила 
e БП-1: Источник и приёмник файлов 


° БП-1.1: Каталоги, являющиеся источником исходным (опечатка, исходных) (Да.) и при- 
ёмником конечных файлов, не должны совпадать. 


= Какова реакция приложения в случае совпадения этих каталогов? (Пишет хелп и 
поясняет, что не так.) 


e БП-1.2: Каталог, являющийся приёмником конечных файлов, не может быть подкатало- 
гом источника (предлагаем заменить слово «источника» на фразу «каталога, являюще- 
гося источником исходных файлов»). (Не надо, непонятно становится.) 

Атрибуты качества 
e АК-1: Производительность 
° АК-1.1: Приложение должно обеспечивать скорость обработки данных 5 МБ/сек. 
a При каких технических характеристиках системы? (17, 4GB КАМ) 
e АК-2: Устойчивость к входным данным 


° АК-2.1: Приложение должно обрабатывать входные файлы размером до 50 МБ вклю- 
чительно. 


= Какова реакция приложения на файлы, размер которых превышает 50 МБ? (He rpo- 
гает.) 


° АК-2.2: Если входной файл не является текстовым, приложение должно произвести 


обработку. 
" Обработкучего должно произвести приложение? (Этого файла. Не важно, что ста- 
нет с файлом, лишь бы скрипт не умер.) 


Здесь есть несколько важных моментов, на которые стоит обратить внимание: 


° Ответы заказчика могут быть менее структурированными и последовательными, чем наши 
вопросы. Это нормально. Он может позволить себе такое, мы — нет. 

e Ответы заказчика могут содержать противоречия (в нашем примере сначала заказчик пи- 
сал, что параметрами, передаваемыми из командной строки, являются только два имени 
каталога, а потом сказал, что там же указывается ИМЯ лог-файла). Это тоже нормально, 
т. к. заказчик мог что-то забыть или перепутать. Наша задача — свести эти противоречивые 
данные воедино (если это возможно) и задать уточняющие вопросы (если это необходимо). 

• В случае если с нами общается технический специалист, в его ответах вполне могут проска- 
кивать технические жаргонизмы (как «хелп» в нашем примере). Не надо переспрашивать 
его о том, что это такое, если жаргонизм имеет однозначное общепринятое значение, но 
при доработке текста наша задача — написать то же самое строгим техническим языком. 
Если жаргонизм всё же непонятен — тогда лучше спросить (так, «хелп» — это всего лишь 
краткая помощь, выводимая консольными приложениями как подсказка о том, как их ис- 
пользовать). 


Уровень продуктных требований (см. главу «Уровни и типы требований» (39). Применимт.н. 
«самостоятельное описание» (см. главу «Источники и пути выявления требований» 7}) и улуч- 
шим требования. Поскольку мы уже получили много специфической технической информации, 
можно параллельно писать полноценную спецификацию требований. Во многих случаях, когда 
для оформления требований используется простой текст, для удобства формируется единый до- 
кумент, который интегрирует в себе как пользовательские требования, так и детальные специ- 
фикации. Теперь требования принимают следующий вид. 
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Системные характеристики 


» СХ-1: Приложение является консольным. 

e СХ-2: Приложение разрабатывается на языке программирования РНР (причина выбора 
языка РНР отражена в пункте О-1 раздела «Ограничения», особенности и важные настрой- 
ки интерпретатора РНР отражены в пункте ДС-1 раздела «Детальные спецификации»). 

e СХ-3: Приложение является кроссплатформенным с учётом пункта О-4 раздела «Ограни- 
чения». 


Пользовательские требования 
• Также см. диаграмму вариантов использования. 


• ПТ-1: Запуск и остановка приложения. 


e ПТ-1.1: Запуск приложения производится из консоли командой «php converter.php 
SOURCE_DIR DESTINATION_DIR [LOG_FILE_NAME]» (описание параметров приве- 
дено в разделе ДС-2.1, реакция на ошибки при указании параметров приведена в разде- 
лах ДС-2.2, ДС-2.3, ДС-2.4). 

° ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C в окне 
консоли, из которого было запущено приложение. 

• ПТ-2: Конфигурирование приложения. 

° ПТ-2.1: Конфигурирование приложения сводится к указанию параметров командной 
строки (см. ДС-2). 

° ПТ-2.2: Целевой кодировкой преобразования текстов является кодировка ОТЕ8 (также 
см. О-5). 

• ПТ-3: Просмотр журнала работы приложения. 


° ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в 
консоль и лог-файл (см. ДС-4), имя которого определяется правилами, указанными 
B ДС-2.1. 

° ПТ-3.2: Формат журнала работы и лог файла указан в ДС-4.1, а реакция приложения на 
наличие или отсутствие лог-файла указана в ДС-4.2 и ДС-4.3 соответственно. 


Бизнес-правила 
• БП-1: Источник и приёмник файлов 
о БП-1.1: Каталоги, являющиеся источником исходных и приёмником конечных файлов, 
не должны совпадать (см. также ДС-2.1 и ДС-3.2). 
° БП-1.2: Каталог, являющийся приёмником конечных файлов, не может находиться 


внутри каталога, являющегося источником исходных файлов или его подкаталогов 
(см. также ДС-2.1 и ДС-3.2). 


Атрибуты качества 
• АК-1: Производительность 
° АК-1.1: Приложение должно обеспечивать скорость обработки данных не менее 


5 МБ/сек на аппаратном обеспечении, эквивалентном следующему: процессор 17, 
4 ГБ оперативной памяти, средняя скорость чтения/записи на диск 30 МБ/сек. Также 
см. О-6. 
• АК-2: Устойчивость к входным данным 

° АК-2.1: Требования относительно форматов обрабатываемых файлов изложены в 
ДС-5.1. 

° АК-2.2: Требования относительно размеров обрабатываемых файлов изложены в 
ДС-5.2. 

° АК-2.3: Поведение приложения в ситуации обработки файлов с нарушениями формата 
определено в ДС-5.3. 
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Ограничения 


О-1: Приложение разрабатывается на языке программирования РНР, использование кото- 
рого обусловлено возможностью заказчика осуществлять поддержку приложения силами 
собственного ІТ-отдела. 

О-2: Ограничения относительно версии и настроек интерпретатора РНР отражены в пункте 
ДС-1 раздела «Детальные спецификации». 

О-3: Процедуры установки и настройки интерпретатора РНР выходят за рамки данного 
проекта и не описываются в документации. 

О-4: Кроссплатформенные возможности приложения сводятся к способности работать под 
ОС семейства Windows и Linux, поддерживающих работу интерпретатора РНР версии, ука- 
занной в ДС-1.1. 

О-5: Целевая кодировка ОТЕЗ является жёстко заданной, и её изменение в процессе эксплу- 
атации приложения не предусмотрено. 

О-6: Допускается невыполнение АК-1.1 в случае, если невозможность обеспечить заявлен- 
ную производительность обусловлена объективными внешними причинами (например, 
техническими проблемами на сервере заказчика). 


Созданные на основе таких пользовательских требований детальные спецификации имеют 
следующий вид. 


Детальные спецификации 


ДС-1: Интерпретатор РНР 


ДС-1.1: Минимальная версия — 5.5. 
ДС-1.2: Для работы приложения должно быть установлено и включено расширение mbstring. 


ДС-2: Параметры командной строки 


ДС-2.1: При запуске приложения оно получает из командной строки три параметра: 


SOURCE_DIR — обязательный параметр, определяет путь к каталогу с файлами, которые 
необходимо обработать; 


DESTINATION_DIR — обязательный параметр, определяет путь к каталогу, в который 
необходимо поместить обработанные файлы (этот каталог не может находиться внутри 
каталога SOURCE_DIR или в его подкаталогах (см. БП-1.1 и БП-1.2)); 


ІОС ЕПЕ МАМЕ — необязательный параметр, определяет полное имя лог-файла 
(по умолчанию лог-файл с именем «converter.log» размещается по тому же пути, по KOTO- 
рому находится файл скрипта сопуецег.рЬр); 


ДС-2.2: При указании недостаточного количества параметров командной строки приложение 
должно завершить работу, выдав сообщение об использовании (ДС-3.1). 

ДС-2.3: При указании излишнего количества параметров командной строки приложение 
должно игнорировать все параметры командной строки, кроме указанных в пункте ДС-2.1. 

ДС-2.4: При указании неверного значения любого из параметров командной строки приложе- 
ние должно завершить работу, выдав сообщение об использовании (ДС-3.1), а также сообщив 
имя неверно указанного параметра, его значение и суть ошибки (см. ДС-3.2). 


ДС-3: Сообщения 


ДС-3.1: Сообщение об использовании: «USAGE converter.php SOURCE_DIR РЕЗТИМАТЮМ_ 
DIR ТОС_ЕПЕ_ МАМЕ». 


ДС-3.2: Сообщения об ошибках: 


Directory not exists or inaccessible. 
Destination dir may not reside within source dir tree. 
Wrong file name or inaccessible path. 
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ДС-4: Журнал работы 


ДС-4.1: Формат журнала работы одинаков для отображения в консоли и записи в лог-файл: 
YYYY-MM-DD НН:1:$$ имя операции параметры _операции результат операции. 

ДС-4.2: В случае если лог-файл отсутствует, должен быть создан новый пустой лог-файл. 

ДС-4.3: В случае если лог-файл уже существует, должно происходить добавление новых запи- 
сей в его конец. 


ДС-5: Форматы и размеры файлов 

ДС-5.1: Приложение должно обрабатывать текстовые файлы на русском и английском языках 
в следующих исходных кодировках: М131251, СР866, КО18К. 

Обрабатываемые файлы могут быть представлены в следующих форматах, определяемых рас- 
ширениями файлов: 


Plain Text (TXT); 
Hyper Text Markup Language Document (HTML); 
Mark Down Document (MD). 


ДС-5.2: Приложение должно обрабатывать файлы размером до 50 МБ (включительно), игно- 
рируя любой файл, размер которого превышает 50 МБ. 
ДС-5.3: Если файл с расширением из ДС-5.1 содержит внутри себя данные, не соответствую- 
щие формату файла, допускается повреждение таких данных. 
Ж ==. Задание 2.2.4: заметили ли вы, что в исправленном варианте требований «потерялась» 
Ө диаграмма вариантов использования (равно как и активная ссылка на неё)? (Просто 
тест на внимательность, не более.) 


Итак, мы получили набор требований, с которым уже вполне можно работать. Он не идеален 
(и никогда вы не встретите идеальных требований), но он вполне пригоден для того, чтобы раз- 
работчики смогли реализовать приложение, а тестировщики — протестировать его. 


\\ Задание 2.2.е: протестируйте этот набор требований и найдите в нём хотя бы 3-5 оши- 
бок и неточностей, задайте соответствующие вопросы заказчику. 
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2.2.8. ТИПИЧНЫЕ ОШИБКИ ПРИ АНАЛИЗЕ 
И ТЕСТИРОВАНИИ ТРЕБОВАНИИ ишкиш 


Для лучшего понимания и запоминания материала рассмотрим типичные ошибки, совершае- 
мые в процессе анализа и тестирования требований. 


Изменение формата файла и документа. По какой-то непонятной причине очень многие на- 
чинающие тестировщики стремятся полностью уничтожить исходный документ, заменив текст 
таблицами (или наоборот), перенеся данные из Word в Excel и т.д. Это можно сделать только в 
одном случае: если вы предварительно договорились о подобных изменениях с автором доку- 
мента. В противном случае вы полностью уничтожаете чью-то работу, делая дальнейшее разви- 
тие документа крайне затруднительным. 

Самое худшее, что можно сделать с документом, — это сохранить его в итоге в некоем форма- 
те, предназначенном скорее для чтения, чем для редактирования (PDF, набор картинок и тому 
подобное). 

Если требования изначально создаются в некоей системе управления требованиями, этот во- 
прос неактуален, но высокоуровневые требования большинство заказчиков привыкли видеть 
в обычном РОСХ-документе, а Word предоставляет такие прекрасные возможности работы с 
документом, как отслеживание изменений (см. рисунок 2.2.1) и комментарии (см. рисунок 2.2.]). 
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Рисунок 2.2.i — Активация отслеживания изменений в Word 


Системные характеристики 


Author 
» СХ-1: Приложение является консольным. 1) Какая минимальная версия интерпретатора РНР 
• СХ-2: Для работы приложение использует интерпретатор PHA, [??7 Ста приложни за 


интерпретатора РНР для корректной работы 
приложения? 


Author 
Должна ли Е руководстве пользователя быть 
описана процелура установки и настройки 


• Также см. диаграмму вариантов использования. 


Пользовательские требования у A 
• ПТ-1: Запуск и остановка приложения. ` ` | 


о ПТ-1 1: Запуск приложения производится из консоли командой "РНР php интерпретатора РНР? 
сопуепег.рһр параметры. ^ ‘| Author 
о ПТ-1.2: Остановка приложения производится выполнением команды `, ` | Formatted Russian 


Рисунок 2.2] — Правильно выглядящий документ с правками 


В итоге получается результат, представленный на рисунке 2.2.): исходный формат сохраняется 
(а автор к нему уже привык), все изменения хорошо видны и могут быть приняты или отклонены 
в пару кликов мыши, а типичные часто повторяющиеся вопросы вы можете помимо указания в 
комментариях вынести в отдельный список и поместить его в том же документе. 


EEEN 2.2. ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ И ТРЕБОВАНИЙ 63 


И ещё два маленьких, но неприятных момента относительно таблиц: 


. Выравнивание ВСЕГО текста в таблице по центру. Да, выравнивание по центру хорошо 
смотрится в заголовках и ячейках с парой-тройкой слов, но если так выровнен весь текст, 
читать его становится сложно. 

• Отключение границ ячеек. Такая таблица намного хуже читается. 


Отметка того факта, что с требованием всё в порядке. Если у вас не возникло вопросов 
и/или замечаний к требованию — не надо об этом писать. Любые пометки в документе подсозна- 
тельно воспринимаются как признак проблемы, и такое «одобрение требований» только раздра- 
жает и затрудняет работу с документом — сложнее становится заметить пометки, относящиеся 
к проблемам. 


Описание одной и той же проблемы в нескольких местах. Помните, что ваши пометки, ком- 
ментарии, замечания и вопросы тоже должны обладать свойствами хороших требований (на- 
столько, насколько эти свойства к ним применимы). Если вы много раз в разных местах пишете 
одно и то же об одном и том же, вы нарушаете как минимум свойство модифицируемости. По- 
старайтесь в таком случае вынести ваш текст в конец документа, укажите в нём же (в начале) 
перечень пунктов требований, к которым он относится, а в самих требованиях в комментариях 
просто ссылайтесь на этот текст. 


Написание вопросов и комментариев без указания места требования, к которым они от- 
носятся. Если ваше инструментальное средство позволяет указать часть требования, к которо- 
му вы пишете вопрос или комментарий, сделайте это (например, Word позволяет выделить для 
комментирования любую часть текста — хоть один символ). Если это невозможно, цитируйте 
соответствующую часть текста. В противном случае вы порождаете неоднозначность или вовсе 
делаете вашу пометку бессмысленной, т. к. становится невозможно понять, о чём вообще идёт 
речь. 


Задавание плохо сформулированных вопросов. Эта ошибка была подробно рассмотрена 
выше (см. раздел «Техники тестирования требований» {50} и таблицу 2.2.а1°!}). Однако добавим, 
что есть ещё три вида плохих вопросов: 


e Первый вид возникает из-за того, что автор вопроса не знает общепринятой терминоло- 
гии или типичного поведения стандартных элементов интерфейса (например, «что та- 
кое чек-бокс?», «как в списке можно выбрать несколько пунктов?», «как подсказка может 
всплывать?»). 

• Второй вид плохих вопросов похож на первый из-за формулировок: вместо того, чтобы Ha- 
писать «что вы имеете в виду под {чем-то} 3», автор вопроса пишет «что такое {что-то}?» 
То есть вместо вполне логичного уточнения получается ситуация, очень похожая на pac- 
смотренную в предыдущем пункте. 

• Третий вид сложно привязать к причине возникновения, но его суть в том, что к некоррект- 
ному и/или невыполнимому требованию задаётся вопрос наподобие «что будет, если мы это 
сделаем». Ничего не будет, т.к. мы это точно не сделаем. И вопрос должен быть совершенно 
иным (каким именно — зависит от конкретной ситуации, но точно не таким). 


И ещё раз напомним о точности формулировок: иногда одно-два слова могут на корню унич- 
тожить отличную идею, превратив хороший вопрос в плохой. Сравните: «Что такое формат даты 
по умолчанию?» и «Каков формат даты по умолчанию». Первый вариант просто показывает 
некомпетентность автора вопроса, тогда как второй — позволяет получить полезную информа- 
ЦИЮ. 

К этой же проблеме относится непонимание контекста. Часто можно увидеть вопросы в стиле 
«о каком приложении идёт речь?», «что такое система?» и им подобные. Чаще всего автор таких 
вопросов просто вырвал требование из контекста, по которому было совершенно ясно, о чём 
идёт речь. 
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Написание очень длинных комментариев и/или вопросов. История знает случаи, когда одна 
страница исходных требований превращалась в 20-30 страниц текста анализа и вопросов. Это 
плохой подход. Все те же мысли можно выразить значительно более кратко, чем сэкономить как 
своё время, так и время автора исходного документа. Тем более стоит учитывать, что на началь- 
ных стадиях работы с требованиями они весьма нестабильны, и может получиться так, что ваши 
5-10 страниц комментариев относятся к требованию, которое просто удалят или изменят до 
неузнаваемости. 


Критика текста или даже его автора. Помните, что ваша задача — сделать требования лучше, 
а не показать их недостатки (или недостатки автора). Потому комментарии вида «плохое требо- 
вание», «неужели вы не понимаете, как глупо это звучит», «надо переформулировать» неуместны 
и недопустимы. 


Категоричные заявления без обоснования. Как продолжение ошибки «критика текста или 
даже его автора» можно отметить и просто категоричные заявления наподобие «это невозмож- 
но», «мы не будем этого делать», «это не нужно». Даже если вы понимаете, что требование бес- 
смысленно или невыполнимо, эту мысль стоит сформулировать в корректной форме и допол- 
нить вопросами, позволяющими автору документа самому принять окончательное решение. 
Например, «это не нужно» можно переформулировать так: «Мы сомневаемся в том, что данная 
функция будет востребована пользователями. Какова важность этого требования? Уверены ли 
вы в его необходимости?» 


Указание проблемы с требованиями без пояснения её сути. Помните, что автор исходного 
документа может не быть специалистом по тестированию или бизнес-анализу. Потому просто 
пометка в стиле «неполнота», «двусмысленность» и т.д. могут ничего ему не сказать. Поясняйте 
свою МЫСЛЬ. 

Сюда же можно отнести небольшую, но досадную недоработку, относящуюся к противоре- 
чивости: если вы обнаружили некие противоречия, сделайте соответствующие пометки во всех 
противоречащих друг другу местах, а не только в одном из них. Например, вы обнаружили, что 
требование 20 противоречит требованию 30. Тогда в требовании 20 отметьте, что оно противо- 
речит требованию 30, и наоборот. И поясните суть противоречия. 


Плохое оформление вопросов и комментариев. Старайтесь сделать ваши вопросы и коммен- 
тарии максимально простыми для восприятия. Помните не только о краткости формулировок, 
но и об оформлении текста (см., например, как на рисунке 2.2.) вопросы структурированы в виде 
списка — такая структура воспринимается намного лучше, чем сплошной текст). Перечитайте 
свой текст, исправьте опечатки, грамматические и пунктуационные ошибки и т.д. 


Описание проблемы не втом месте, к которому она относится. Классическим примером мо- 
жет быть неточность в сноске, приложении или рисунке, которая почему-то описана не там, где 
она находится, а в тексте, ссылающемся на соответствующий элемент. Исключением может счи- 
таться противоречивость, при которой описать проблему нужно в обоих местах. 


Ошибочное восприятие требования как «требования к пользователю». Ранее (см. «Кор- 
ректность» в «Свойства качественных требований») мы говорили, что требования в стиле «поль- 
зователь должен быть в состоянии отправить сообщение» являются некорректными. И это так. 
Но бывают ситуации, когда проблема намного менее опасна и состоит только в формулиров- 
ке. Например, фразы в стиле «пользователь может нажать на любую из кнопок», «пользователю 
должно быть видно главное меню» на самом деле означают «все отображаемые кнопки должны 
быть доступны для нажатия» и «главное меню должно отображаться». Да, эту недоработку тоже 
стоит исправить, но не следует отмечать её как критическую проблему. 


Скрытое редактирование требований. Эту ошибку можно смело отнести к разряду край- 
не опасных. Её суть состоит в том, что тестировщик произвольно вносит правки в требования, 
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никак не отмечая этот факт. Соответственно, автор документа, скорее всего, не заметит такой 
правки, а потом будет очень удивлён, когда в продукте что-то будет реализовано совсем не так, 
как когда-то было описано в требованиях. Потому простая рекомендация: если вы что-то прави- 
те, обязательно отмечайте это (средствами вашего инструмента или просто явно в тексте). И ещё 
лучше отмечать правку как предложение по изменению, а не как свершившийся факт, т. к. автор 
исходного документа может иметь совершенно иной взгляд на ситуацию. 


Анализ, не соответствующий уровню требований. При тестировании требований следует 
постоянно помнить, к какому уровню они относятся, т.к. в противном случае появляются сле- 
дующие типичные ошибки: 

„ Добавление в бизнес-требования мелких технических подробностей. 

e Дублирование на уровне пользовательских требований части бизнес-требований (если вы 
хотите увеличить прослеживаемость набора требований, имеет смысл просто использовать 
ссылки). 

• Недостаточная детализация требований уровня продукта (общие фразы, допустимые, Ha- 
пример, на уровне бизнес-требований, здесь уже должны быть предельно детализированы, 
структурированы и дополнены подробной технической информацией). 
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ВИДЫ И НАПРАВЛЕНИЯ 
ТЕСТИРОВАНИЯ 


2.3.1. УПРОЩЕННАЯ КЛАССИФИКАЦИЯ 
ТЕСТИРОВАНИЯ шшш 


Тестирование можно классифицировать по очень большому количеству признаков, и практи- 
чески в каждой серьёзной книге о тестировании автор показывает свой (безусловно имеющий 
право на существование) взгляд на этот вопрос. 

Соответствующий материал достаточно объёмен и сложен, а глубокое понимание каждого 
пункта в классификации требует определённого опыта, потому мы разделим данную тему на две: 
сейчас мы рассмотрим самый простой, минимальный набор информации, необходимый начи- 
нающему тестировщику, а в следующей главе приведём подробную классификацию. 

Используйте нижеприведённый список как очень краткую «шпаргалку для запоминания». 
Итак, тестирование можно классифицировать: 


Упрощённая классификация тестирования 


По запуску кода на исполнение По доступу к коду и архитектуре приложения По степени автоматизации 


Метод белого Метод чёрного Метод серого 
ящика ящика ящика 


Статическое Динамическое Ручное Автоматизированное 


По (убыванию) степени важности тестируемых 


функций По принципам работы с приложением 


По уровню детализации приложения 


«Дымовое» Критического 


Расширенное Позитивное Негативное 
(«смоук») пути 


Модульное Интеграционное Системное 


Рисунок 2.3.а — Упрощённая классификация тестирования 


• По запуску кода на исполнение: 

° Статическое тестирование — без запуска. 

° Динамическое тестирование — с запуском. 
• По доступу к коду и архитектуре приложения: 


° Метод белого ящика — доступ к коду есть. 
° Метод чёрного ящика — доступа к коду нет. 
° Метод серого ящика — к части кода доступ есть, к части — нет. 


e По степени автоматизации: 


е Ручное тестирование — тест-кейсы выполняет человек. 
о Автоматизированное тестирование — тест-кейсы частично или полностью выполняет 
специальное инструментальное средство. 
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e По уровню детализации приложения (по уровню тестирования): 


° Модульное (компонентное) тестирование — проверяются отдельные небольшие части 
приложения. 

° Интеграционное тестирование — проверяется взаимодействие между несколькими 
частями приложения. 

° Системное тестирование — приложение проверяется как единое целое. 


• По (убыванию) степени важности тестируемых функций (по уровню функционального TeC- 
тирования): 


° Дымовое тестирование (обязательно изучите этимологию термина — хотя бы в Википе- 
дии!09) — проверка самой важной, самой ключевой функциональности, неработоспо- 
собность которой делает бессмысленной саму идею использования приложения. 

° Тестирование критического пути — проверка функциональности, используемой ти- 
пичными пользователями в типичной повседневной деятельности. 

° Расширенное тестирование — проверка всей (остальной) функциональности, заявлен- 
ной в требованиях. 


• По принципам работы с приложением: 


° Позитивное тестирование — все действия с приложением выполняются строго по ин- 
струкции без никаких недопустимых действий, некорректных данных ит.д. Можно 06- 
разно сказать, что приложение исследуется в «тепличных условиях». 

° Негативное тестирование — в работе с приложением выполняются (некорректные) 
операции и используются данные, потенциально приводящие к ошибкам (классика 
жанра — деление на ноль). 


Внимание! Очень частая ошибка! Негативные тесты НЕ предполагают возникновения 
в приложении ошибки. Напротив — они предполагают, что верно работающее прило- 
жение даже в критической ситуации поведёт себя правильным образом (в примере с 
делением на ноль, например, отобразит сообщение «Делить на ноль запрещено»). 


Часто возникает вопрос о том, чем различаются «тип тестирования», «вид тестирования», 
«способ тестирования», «подход к тестированию» и т.д. и т.п. Если вас интересует строгий фор- 
мальный ответ, посмотрите в направлении таких вещей как «таксономия!» и «таксон», 
т.к. сам вопрос выходит за рамки тестирования как такового и относится уже к области науки. 

Но исторически так сложилось, что как минимум «тип тестирования» (testing type) и «вид Tec- 
тирования» (testing kind) давно стали синонимами. 


109 «Smoke test», Wikipedia [http://en.wikipedia.org/wiki/Smoke_testing_(electrical)] 
110 «Таксономия», Wikipedia [https://ru.wikipedia.org/wiki/Takconomna] 
ИТ «Таксон», Wikipedia [https://ru.wikipedia.org/wiki/Taxcon] 
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2.3.2. ПОДРОБНАЯ КЛАССИФИКАЦИЯ 
ТЕСТИРОВАНИЯ mamm 


2.3.2.1. СХЕМА КЛАССИФИКАЦИИ ТЕСТИРОВАНИЯ 


Теперь мы рассмотрим классификацию тестирования максимально подробно. Настоятельно 
рекомендуется прочесть не только текст этой главы, но и все дополнительные источники, на ко- 
торые будут приведены ссылки. 

На рисунках 2.3.Ь и 2.3.с приведена схема, на которой все способы классификации показаны 
одновременно. Многие авторы, создававшие подобные классификации!12, использовали интел- 
лект-карты, однако такая техника не позволяет в полной мере отразить тот факт, что способы 
классификации пересекаются (т.е. некоторые виды тестирования можно отнести к разным спо- 
собам классификации). На рисунках 2.3.6 и 2.3.с самые яркие случаи таких пересечений отмече- 
ны цветом (см. полноразмерный электронный вид рисунка115) и границей блоков в виде набора 
точек. Если вы видите на схеме подобный блок — ищите одноимённый где-то в другом виде 
классификации. 


• прекрасную статью «Классификация видов тестирования»! 12; 

• также классическую книгу Ли Коупленда «Практическое руководство по разработке 
тестов» (Lee Copeland, «А РгасННопег5 Guide to Software Test Design»); 

e очень интересную заметку «Types of Software Testing: List of 100 Different Testing 
Туреѕ» 113. 


© Настоятельно рекомендуется в дополнение к материалу этой главы прочесть: 


Зачем вообще нужна классификация тестирования? Она позволяет упорядочить знания и зна- 
чительно ускоряет процессы планирования тестирования и разработки тест-кейсов, а также по- 
зволяет оптимизировать трудозатраты за счёт того, что тестировщику не приходится изобретать 
очередной велосипед. 

При этом ничто не мешает создавать собственные классификации — как вообще придуман- 
ные с нуля, так и представляющие собой комбинации и модификации представленных ниже 
классификаций. 


сказать, что в материалах! 14 ISTQB приведён наиболее обобщённый и общепринятый 
взгляд на этот вопрос, но и там нет единой схемы, которая объединяла бы все варианты 
классификации. 


Если вас интересует некая «эталонная классификация», то... её не существует. Можно 


Так что, если вас просят рассказать о классификации тестирования, стоит уточнить, 
согласно какому автору или источнику спрашивающий ожидает услышать ваш ответ. 


Сейчас вы приступите к изучению одного из самых сложных разделов этой книги. Если вы 
уже имеете достаточный опыт в тестировании, можете отталкиваться от схемы, чтобы систе- 
матизировать и расширить свои знания. Если вы только начинаете заниматься тестированием, 
рекомендуется сначала прочитать текст, следующий за схемой. 


112 «Классификация видов тестирования» [http://habrahabr.ru/company/npo-comp/blog/223833/] 


113 «Types of Software Testing: List of 100 Different Testing Types» [http://www.guru99.com/types-of-software-testing. 
html] 


114 International Software Testing Qualifications Board, Downloads. [http://www.istqb.org/downloads.html] 
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вопросы, почему функциональное и нефункциональное тестирование не связано с со- 


© По поводу схем, которые вы сейчас увидите на рисунках 2.3.b и 2.3.с, часто поступают 
ответствующими подвидами. Тому есть две причины: 


1) Несмотря на то что те или иные виды тестирования принято причислять к функцио- 
нальному или нефункциональному тестированию, в них всё равно присутствуют обе 
составляющие (как функциональная, так и нефункциональная), пусть и в разных про- 
порциях. Более того: часто проверить нефункциональную составляющую невозможно, 
пока не будет реализована соответствующая функциональная составляющая. 


2) Схема превратилась бы в непроглядную паутину линий. 


Потому было решено оставить рисунки 2.3.b и 2.3.с в том виде, в каком они представ- 
лены на следующих двух страницах. Полноразмерный вариант этих рисунков можно 
скачать здесь 5. 


Итак, тестирование можно классифицировать... 


115 Полноразмерный вариант рисунков 2.3.6 [http://svyatoslav.biz/wp-pics/software_testing_classification_ru.png] и 
2.3.с [http://svyatoslav.biz/wp-pics/software_testing_classification_en.png] 
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Классификация тестирования 


По запуску кода на исполнение По доступу к коду и архитектуре приложения По степени автоматизации 
Статическое Динамическое Метод белого Метод чёрного Ба Автоматизированное 
тестирование тестирование ящика ящика У (и «автоматическое») 

По уровню детализации приложения По (убыванию) степени важности тестируемых 
А По природе приложения 
(по уровню тестирования) функций (по уровню функционального тестирования) 


| | | | | 


Модульное Интеграционное Системное «Дымовое» Критического 
ду р Д Расширенное Веб Мобильное | | Настольное 
тестирование тестирование тестирование («смоук») пути 
По фокусировке на уровне архитектуры приложения По привлечению конечных пользователей По степени формализации 
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Рисунок 2.3.6 — Подробная классификация тестирования (русскоязычный вариант) 
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2.3.2.2. КЛАССИФИКАЦИЯ ПО ЗАПУСКУ КОДА НА ИСПОЛНЕНИЕ 


Далеко не всякое тестирование предполагает взаимодействие с работающим приложением. 
Потому в рамках данной классификации выделяют: 


e Статическое тестирование (static testing! 16) — тестирование без запуска кода на исполне- 
ние. В рамках этого подхода тестированию могут подвергаться: 


° Документы (требования, тест-кейсы, описания архитектуры приложения, схемы баз 
данных и т.д.). 

° Графические прототипы (например, эскизы пользовательского интерфейса). 

° Код приложения (что часто выполняется самими программистами в рамках аудита кода 
(code геем 17), являющегося специфической вариацией взаимного просмотра} в 
применении к исходному коду). Код приложения также можно проверять с использо- 
ванием техник тестирования на основе структур кода. 

° Параметры (настройки) среды исполнения приложения. 

° Подготовленные тестовые данные. 


. Динамическое тестирование (dynamic testing!!8) — тестирование с запуском кода на ис- 
полнение. Запускаться на исполнение может как код всего приложения целиком (системное 
тестирование!78}), так и код нескольких взаимосвязанных частей (интеграционное тести- 
рование!77}), отдельных частей (модульное или компонентное тестирование 7}) и даже от- 
дельные участки кода. Основная идея этого вида тестирования состоит в том, что проверя- 
ется реальное поведение (части) приложения. 


116 Static testing. Testing of a software development artifact, e.g., requirements, design ог code, without execution of these 
artifacts, e.g., reviews or static analysis. [ISTQB Glossary] 

117 Jason Cohen, «Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.)». Официально pac- 
пространяемую электронную версию книги можно взять здесь: http://smartbear.com/SmartBear/media/pdfs/best-kept- 
secrets-of-peer-code-review.pdf 

118 Dynamic testing. Testing that involves the execution of the software of a component or system. [ISTQB Glossary] 
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2.3.2.3. КЛАССИФИКАЦИЯ ПО ДОСТУПУ К КОДУ 
И АРХИТЕКТУРЕ ПРИЛОЖЕНИЯ 


• Метод белого ящика (white box (езНпо!19, open box testing, clear box testing, glass box testing) — 
y тестировщика есть доступ K внутренней структуре и коду приложения, а также есть доста- 
точно знаний для понимания увиденного. Выделяют даже сопутствующую тестированию по 
методу белого ящика глобальную технику — тестирование на основе дизайна (design-based 
testing!?0). Для более глубокого изучения сути метода белого ящика рекомендуется озна- 
комиться с техниками исследования потока управления{ 8} или потока данных}, исполь- 
зования диаграмм состояний}. Некоторые авторы склонны жёстко связывать этот метод 
со статическим тестированием, но ничто не мешает тестировщику запустить код на выпол- 
нение и при этом периодически обращаться к самому коду (а модульное тестирование 7} 
и вовсе предполагает запуск кода на исполнение и при этом работу именно с кодом, а нес 
«приложением целиком»). 


e Метод чёрного ящика (black Бох testing!?!, closed box testing, зресйсаНоп-Базе4 testing) — 
у тестировщика либо нет доступа к внутренней структуре и коду приложения, либо недо- 
статочно знаний для их понимания, либо он сознательно не обращается к ним в процессе 
тестирования. При этом абсолютное большинство перечисленных на рисунках 2.3.Ъ и 2.3.с 
видов тестирования работают по методу чёрного ящика, идею которого в альтернативном 
определении можно сформулировать так: тестировщик оказывает на приложение воздей- 
ствия (и проверяет реакцию) тем же способом, каким при реальной эксплуатации приложе- 
ния на него воздействовали бы пользователи или другие приложения. В рамках тестирова- 
ния по методу чёрного ящика основной информацией для создания тест-кейсов выступает 
документация (особенно — требования (requirements-based testing!??)) и общий здравый 
смысл (для случаев, когда поведение приложения в некоторой ситуации не регламентирова- 
но явно; иногда это называют «тестированием на основе неявных требований», но канони- 
ческого определения у этого подхода нет). 


e Метод серого ящика (gray Бох testing!?3) — комбинация методов белого ящика и чёрного 
ящика, состоящая в том, что к части кода и архитектуры у тестировщика доступ есть, а к 
части — нет. На рисунках 2.3. и 2.3.с этот метод обозначен особым пунктиром и серым 
цветом потому, что его явное упоминание — крайне редкий случай: обычно говорят о мето- 
дах белого или чёрного ящика в применении к тем или иным частям приложения, при этом 
понимая, что «приложение целиком» тестируется по методу серого ящика. 


119 White box testing. Testing based оп ап analysis of the internal structure of the component ог system. [ISTQB Glossary] 

120 Design-based Testing. An approach to testing in which test cases are designed based on the architecture and/or detailed 
design of a component or system (e.g. tests of interfaces between components or systems). [ISTQB Glossary] 

121 Black box testing. Testing, either functional or non-functional, without reference to the internal structure of the 
component or system. [ISTQB Glossary] 

122 Requirements-based Testing. An approach to testing in which test cases are designed based on test objectives and 
test conditions derived from requirements, e.g. tests that exercise specific functions or probe non-functional attributes such as 
reliability or usability. [ISTQB Glossary] 

123 Gray box testing is a software testing method, which is a combination of Black Box Testing method and White Box 
Testing method. ... In Gray Box Testing, the internal structure is partially known. This involves having access to internal data 
structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. [«Gray Box Testing 
Fundamentals», http://softwaretestingfundamentals.com/gray-box-testing]. 
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Важно! Некоторые авторы!24 определяют метод серого ящика как противопоставле- 
ние методам белого и чёрного ящика, особо подчёркивая, что при работе по методу 
серого ящика внутренняя структура тестируемого объекта известна частично и выяс- 
няется по мере исследования. Этот подход, бесспорно, имеет право на существование, 
но в своём предельном случае он вырождается до состояния «часть системы мы знаем, 
часть — не знаем», т. е. до всё той же комбинации белого и чёрного ящиков. 


Если сравнить основные преимущества и недостатки перечисленных методов, получается сле- 
дующая картина (см. таблицу 2.3.а). 
Методы белого и чёрного ящика не являются конкурирующими или взаимоисключающими — 
напротив, они гармонично дополняют друг друга, компенсируя таким образом имеющиеся не- 


достатки. 


Таблица 2.3.а — Преимущества и недостатки методов белого, чёрного и серого ящиков 


Преимущества 


Недостатки 


Метод 
белого 
ящика 


• Показывает скрытые проблемы и упро- 
щает их диагностику. 

• Допускает достаточно простую автома- 
тизацию тест-кейсов и их выполнение 
на самых ранних стадиях развития про- 
екта. 

e Обладает развитой системой метрик, 
сбор и анализ которых легко автомати- 
зируется. 

• Стимулирует разработчиков к написа- 
нию качественного кода. 

° Многие техники этого метода являются 
проверенными, хорошо себя зарекомен- 
довавшими решениями, базирующими- 
ся на строгом техническом подходе. 


Не может выполняться тестировщи- 
ками, не обладающими достаточными 
знаниями в области программирова- 
ния. 

Тестирование сфокусировано на реали- 
зованной функциональности, что повы- 
шает вероятность пропуска нереализо- 
ванных требований. 

Поведение приложения исследуется в 
отрыве от реальной среды выполнения 
и не учитывает её влияние. 

Поведение приложения исследуется в 
отрыве от реальных пользовательских 
сценариев{148}. 


Метод 
чёрного 
ящика 


• Тестировщик не обязан обладать (глу- 
бокими) знаниями в области програм- 
мирования. 

• Поведение приложения исследуется в 
контексте реальной среды выполнения 
и учитывает её влияние. 

• Поведение приложения исследуется в 
контексте реальных пользовательских 
сценариев 48}. 

• Тест-кейсы можно создавать уже на CTA- 
дии появления стабильных требований. 

• Процесс создания тест-кейсов позволя- 
ет выявить дефекты в требованиях. 

e Допускает создание тест-кейсов, KOTO- 
рые можно многократно использовать 
на разных проектах. 


Возможно повторение части тест-кей- 
сов, уже выполненных разработчиками. 
Высока вероятность того, что часть воз- 
можных вариантов поведения приложе- 
ния останется непротестированной. 
Для разработки высокоэффективных 
тест-кейсов необходима качественная 
документация. 

Диагностика обнаруженных дефектов 
более сложна в сравнении с техниками 
метода белого ящика. 

В связи с широким выбором техник и 
подходов затрудняется планирование и 
оценка трудозатрат. 

В случае автоматизации могут потребо- 
ваться сложные дорогостоящие инстру- 
ментальные средства. 


Метод 
серого 
ящика 


Сочетает преимущества и недостатки методов белого и чёрного ящика. 


124 «Gray box testing (gray box) definition», Margaret Rouse [http://searchsoftwarequality.techtarget.com/definition/ 


gray-box] 
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2.3.2.4. КЛАССИФИКАЦИЯ ПО СТЕПЕНИ АВТОМАТИЗАЦИИ 


e Ручное тестирование (manual їезїїпр!?^) — тестирование, в котором тест-кейсы выполня- 
ются человеком вручную без использования средств автоматизации. Несмотря на то что это 
звучит очень просто, от тестировщика в те или иные моменты времени требуются такие 
качества, как терпеливость, наблюдательность, креативность, умение ставить нестандарт- 
ные эксперименты, а также умение видеть и понимать, что происходит «внутри системы», 
т.е. как внешние воздействия на приложение трансформируются в его внутренние про- 
цессы. 


e Автоматизированное тестирование (automated testing, test automation126) — набор техник, 
ПОДХОДОВ И инструментальных средств, позволяющий исключить человека из выполнения 
некоторых задач в процессе тестирования. Тест-кейсы частично или полностью выполняет 
специальное инструментальное средство, однако разработка тест-кейсов, подготовка дан- 
ных, оценка результатов выполнения, написания отчётов об обнаруженных дефектах = 
всё это и многое другое по-прежнему делает человек. 


= Некоторые авторы!12 говорят отдельно о «полуавтоматизированном» тестировании 
как варианте ручного с частичным использованием средств автоматизации и отдельно 
об «автоматизированном» тестировании (относя туда области тестирования, в кото- 
рых компьютер выполняет ощутимо большой процент задач). Но т.к. без участия чело- 
века всё равно не обходится ни один из этих видов тестирования, не станем усложнять 
набор терминов и ограничимся одним понятием «автоматизированное тестирование». 


125 Manual testing is performed Бу the tester who carries out all the actions оп the tested application manually, step Бу step 
and indicates whether a particular step was accomplished successfully or whether it failed. Manual testing is always a part of 
any testing effort. It is especially useful in the initial phase of software development, when the software and its user interface are 
not stable enough, and beginning the automation does not make sense. (SmartBear TestComplete user manual, http://support. 
smartbear.com/viewarticle/55004/) 

126 Test automation is the use of software to control the execution of tests, the comparison of actual outcomes to 
predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions. Commonly, test 
automation involves automating a manual process already in place that uses a formalized testing process. (Ravinder Veer Hooda, 
“An Automation of Software Testing: A Foundation for the Future” 
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У автоматизированного тестирования есть много как сильных, так и слабых сторон (см. таб- 
лицу 2.3.5). 


Таблица 2.3.6 — Преимущества и недостатки автоматизированного тестирования 


Преимущества 


Недостатки 


Скорость выполнения тест-кейсов может в 
разы и на порядки превосходить возможно- 
сти человека. 

Отсутствие влияния человеческого фактора 
в процессе выполнения тест-кейсов (устало- 
сти, невнимательности и т.д.) 

Минимизация затрат при многократном 
выполнении тест-кейсов (участие человека 
здесь требуется лишь эпизодически). 
Способность средств автоматизации выпол- 
нить тест-кейсы, в принципе непосильные 
для человека в силу своей сложности, скоро- 
сти или иных факторов. 

Способность средств автоматизации соби- 
рать, сохранять, анализировать, агрегиро- 
вать и представлять в удобной для восприя- 
тия человеком форме колоссальные объёмы 
данных. 

Способность средств автоматизации выпол- 
нять низкоуровневые действия с приложе- 
нием, операционной системой, каналами пе- 
редачи данных ит. д. 


Необходим высококвалифицированный 
персонал в силу того факта, что автоматиза- 
ция — это «проект внутри проекта» (со сво- 
ими требованиями, планами, кодом и т. д.) 
Высокие затраты на сложные средства ав- 
томатизации, разработку и сопровождение 
кода тест-кейсов. 

Автоматизация требует более тщательного 
планирования и управления рисками, т. к. в 
противном случае проекту может быть нане- 
сён серьёзный ущерб. 

Средств автоматизации крайне много, что 
усложняет проблему выбора того или иного 
средства и может повлечь за собой финансо- 
вые затраты (и риски), необходимость обу- 
чения персонала (или поиска специалистов). 
В случае ощутимого изменения требований, 
смены технологического домена, переработ- 
ки интерфейсов (как пользовательских, так 
и программных) многие тест-кейсы стано- 
вятся безнадёжно устаревшими и требуют 
создания заново. 


Если же выразить все преимущества и недостатки автоматизации тестирования одной фра- 
зой, то получается, что автоматизация позволяет ощутимо увеличить тестовое покрытие (test 
соуегаре!?7), но при этом столь же ощутимо увеличивает риски. 


Задание 2.3.а: сформируйте аналогичную таблицу с преимуществами и недостатками 
ручного тестирования. Подсказка: здесь недостаточно просто поменять заголовки ко- 
лонок с преимуществами и недостатками автоматизации. 


127 Coverage, Test coverage. The degree, expressed as а percentage, to which а specified coverage item has been exercised 
by a test suite. [ISTQB Glossary] 
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2.3.2.5. КЛАССИФИКАЦИЯ ПО УРОВНЮ ДЕТАЛИЗАЦИИ ПРИЛОЖЕНИЯ 
(ПО УРОВНЮ ТЕСТИРОВАНИЯ) 


классификаций не существует, и две из них имеют очень схожие названия: 

• «По уровню детализации приложения» = «по уровню тестирования». 

• «По (убыванию) степени важности тестируемых функций» = «по уровню функцио- 
нального тестирования». 


@ Внимание! Возможна путаница, вызванная тем, что единого общепринятого набора 


• Модульное (компонентное) тестирование (unit testing, module testing, component testing!?8) 
направлено на проверку отдельных небольших частей приложения, которые (как правило) 
можно исследовать изолированно от других подобных частей. При выполнении данного тес- 
тирования могут проверяться отдельные функции или методы классов, сами классы, взаи- 
модействие классов, небольшие библиотеки, отдельные части приложения. Часто данный 
вид тестирования реализуется с использованием специальных технологий и инструмен- 
тальных средств автоматизации тестирования S}, значительно упрощающих и ускоряющих 
разработку соответствующих тест-кейсов. 


«юнит-тестирование», как правило, направлено на тестирование атомарных участков 
кода, «модульное» — на тестирование классов и небольших библиотек, «компонент- 
ное» — на тестирование библиотек и структурных частей приложения. Но эта класси- 
фикация не стандартизирована, и у различных авторов можно встретить совершенно 
разные взаимоисключающие трактовки. 


© Из-за особенностей перевода на русский язык теряются нюансы степени детализации: 


e Интеграционное тестирование (integration testing!??, component integration testing!?0, 
pairwise integration ќеѕііпр13!, system integration testing!?2, incremental ќеѕііпр!33, interface 
testing!34, thread testing!35) направлено на проверку взаимодействия между несколькими 
частями приложения (каждая из которых, в свою очередь, проверена отдельно на стадии 
модульного тестирования). К сожалению, даже если мы работаем с очень качественными 
отдельными компонентами, «на стыке» их взаимодействия часто возникают проблемы. 
Именно эти проблемы и выявляет интеграционное тестирование. (См. также техники вос- 
ходящего, нисходящего и гибридного тестирования в хронологической классификации по 
иерархии компонентов 03}.) 


128 Module testing, Unit testing, Component testing. The testing of individual software components. [ISTQB Glossary] 

129 Integration testing. Testing performed to expose defects in the interfaces and in the interactions between integrated 
components or systems. [ISTQB Glossary] 

130 Component integration testing. Testing performed to expose defects in the interfaces and interaction between 
integrated components. [ISTQB Glossary] 

131 Pairwise integration testing. A form of integration testing that targets pairs of components that work together, as 
shown in a call graph. [ISTQB Glossary] 

132 System integration testing. Testing the integration of systems and packages; testing interfaces to external organizations 
(e.g. Electronic Data Interchange, Internet). [ISTQB Glossary] 

133 Incremental testing. Testing where components or systems are integrated and tested one or some at a time, until all the 
components or systems are integrated and tested. [ISTQB Glossary] 

134 Interface testing. An integration test type that is concerned with testing the interfaces between components or systems. 
[ISTQB Glossary] 

135 Thread testing. An approach to component integration testing where the progressive integration of components follows 
the implementation of subsets of the requirements, as opposed to the integration of components by levels of a hierarchy. [ISTQB 
Glossary] 
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e Системное тестирование (system testing!36) направлено на проверку всего приложения как 
единого целого, собранного из частей, проверенных на двух предыдущих стадиях. Здесь не 
только выявляются дефекты «на стыках» компонентов, но и появляется возможность пол- 
ноценно взаимодействовать с приложением с точки зрения конечного пользователя, приме- 
няя множество других видов тестирования, перечисленных в данной главе. 


С классификацией по уровню детализации приложения связан интересный печальный факт: 
если предыдущая стадия обнаружила проблемы, то на следующей стадии эти проблемы точно 
нанесут удар по качеству; если же предыдущая стадия не обнаружила проблем, это ещё никоим 
образом не защищает нас от проблем на следующей стадии. 

Для лучшего запоминания степень детализации в модульном, интеграционном и системном 
тестировании показана схематично на рисунке 2.3.4. 

Если обратиться к словарю ISTQB и прочитать определение уровня тестирования (test level!37), 
то можно увидеть, что аналогичное разбиение на модульное, интеграционное и системное тес- 
тирование, к которым добавлено ещё и приёмочное тестирование, используется в контексте 
разделения областей ответственности на проекте. Но такая классификация больше относится к 
вопросам управления проектом, чем к тестированию в чистом виде, а потому выходит за рамки 
рассматриваемых нами вопросов. 


посмотреть в статье «What are Software Testing 1.еуе1$?138». Для улучшения запоминания 
отразим эту идею на рисунке 2.3.е, но отметим, что это скорее общий теоретический 
взгляд. 


© Самый полный вариант классификации тестирования по уровню тестирования можно 


136 System testing. The process of testing ап integrated system to verify that it meets specified requirements. [ISTQB 
Glossary] 

137 Test level. A group of test activities that are organized and managed together. A test level is linked to the responsibilities 
in a project. Examples of test levels are component test, integration test, system test and acceptance test. [ISTQB Glossary] 


138 «What are Software Testing Levels?» [http://istqbexamcertification.com/what-are-software-testing-levels/] 
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Рисунок 2.3.4 — Схематичное представление классификации тестирования 
по уровню детализации приложения 
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Рисунок 2.3.е — Самый полный вариант классификации тестирования 
по уровню тестирования 
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2.3.2.6. КЛАССИФИКАЦИЯ ПО (УБЫВАНИЮ) СТЕПЕНИ ВАЖНОСТИ 
ТЕСТИРУЕМЫХ ФУНКЦИИ 
(ПО УРОВНЮ ФУНКЦИОНАЛЬНОГО ТЕСТИРОВАНИЯ) 


В некоторых источниках эту разновидность классификации также называют «по глубине те- 
стирования». 
72 Внимание! Возможна путаница, вызванная тем, что единого общепринятого набора 
@ классификаций не существует, и две из них имеют очень схожие названия: 
• «По уровню детализации приложения» = «по уровню тестирования». 
„ «По (убыванию) степени важности тестируемых функций» = «по уровню функцио- 
нального тестирования» 


• Дымовое тестирование (smoke {ез 139, intake test!40, build verification test!41) направлено на 
проверку самой главной, самой важной, самой ключевой функциональности, неработоспо- 
собность которой делает бессмысленной саму идею использования приложения (или иного 
объекта, подвергаемого дымовому тестированию). 

2 Внимание! Очень распространённая проблема! Из-за особенности перевода на русский 
@ язык под термином «приёмочное тестирование» часто может пониматься как «smoke 
test»{80}, так и «acceptance {ез» {89}, которые изначально не имеют между собою ничего 


общего. Возможно, в том числе поэтому многие тестировщики почти не используют 
русский перевод «дымовое тестирование», а так и говорят — «смоук-тест». 


Дымовое тестирование проводится после выхода нового билда, чтобы определить общий 
уровень качества приложения и принять решение о (не)целесообразности выполнения тес- 
тирования критического пути и расширенного тестирования. Поскольку тест-кейсов на 
уровне дымового тестирования относительно немного, а сами они достаточно просты, но 
при этом очень часто повторяются, они являются хорошими кандидатами на автоматиза- 
цию. В связи с высокой важностью тест-кейсов на данном уровне пороговое значение мет- 


рики их прохождения часто выставляется равным 100 % или близким к 100 %. 


Очень часто можно услышать вопрос о том, чем «smoke test» отличается от «sanity test». 


В глоссарии ISTQB сказано просто: «sanity test: See smoke test». Но некоторые авторы утвер- 


142 


ждают!42, что разница!® есть и может быть выражена следующей схемой (рисунок 2.3.1): 


139 Smoke test, Confidence test, Sanity test. А subset of all defined/planned test cases that cover the main functionality of 
a component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. 
[ISTQB Glossary] 

140 Intake test. A special instance of a smoke test to decide if the component or system is ready for detailed and further 
testing. An intake test is typically carried out at the start of the test execution phase. [ISTQB Glossary] 

141 Build verification test. A set of automated tests which validates the integrity of each new build and verifies its 
key/core functionality, stability and testability. It is an industry practice when a high frequency of build releases occurs 
(e.g., agile projects) and it is run on every new build before the build is released for further testing. [ISTQB Glossary] 

142 «Smoke Vs Sanity Testing — Introduction and Differences» [http://www.guru99.com/smoke-sanity-testing.html] 

143 «Smoke testing and sanity testing — Quick and simple differences» [http://www.softwaretestinghelp.com/smoke- 
testing-and-sanity-testing-difference/] 
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Рисунок 2.3.f — Трактовка разницы между smoke test u sanity test 


• Тестирование критического пути (critical path144 test) направлено на исследование функ- 
циональности, используемой типичными пользователями в типичной повседневной дея- 
тельности. Как видно из определения в сноске к англоязычной версии термина, сама идея 
позаимствована из управления проектами и трансформирована в контексте тестирования 
в следующую: существует большинство пользователей, которые чаще всего используют не- 
кое подмножество функций приложения (см. рисунок 2.3.5). Именно эти функции и нужно 
проверить, как только мы убедились, что приложение «в принципе работает» (дымовой тест 
прошёл успешно). Если по каким-то причинам приложение не выполняет эти функции или 
выполняет их некорректно, очень многие пользователи не смогут достичь множества сво- 
их целей. Пороговое значение метрики успешного прохождения «теста критического пути» 
уже немного ниже, чем в дымовом тестировании, но всё равно достаточно высоко (как пра- 
вило, порядка 70-80-90 % — в зависимости от сути проекта). 


Тестирование 
критического пути 


Рисунок 2.3.5 — Суть тестирования критического пути 


144 Critical path. Longest sequence of activities in а project plan which must be completed оп time for the project to 
complete on due date. An activity on the critical path cannot be started until its predecessor activity is complete; if it is delayed 
for a day, the entire project will be delayed for a day unless the activity following the delayed activity is completed a day earlier. 
[http://www.businessdictionary.com/definition/critical-path.html] 
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• Расширенное тестирование (extended test!45) направлено на исследование всей заявленной 
в требованиях функциональности — даже той, которая низко проранжирована по степе- 
ни важности. При этом здесь также учитывается, какая функциональность является более 
важной, а какая — менее важной. Но при наличии достаточного количества времени и иных 
ресурсов тест-кейсы этого уровня могут затронуть даже самые низкоприоритетные требо- 
вания. 


Ещё одним направлением исследования в рамках данного тестирования являются нетипич- 
ные, маловероятные, экзотические случаи и сценарии использования функций и свойств 
приложения, затронутых на предыдущих уровнях. Пороговое значение метрики успешного 
прохождения расширенного тестирования существенно ниже, чем в тестировании крити- 
ческого пути (иногда можно увидеть даже значения в диапазоне 30-50 %, т.к. подавляющее 
большинство найденных здесь дефектов не представляет угрозы для успешного использова- 
ния приложения большинством пользователей). 


критического пути и расширенное тестирование напрямую связаны с позитивным{83} 
тестированием и негативным{83} тестированием, и негативное появляется только на 
уровне тестирования критического пути. Это не так. Как позитивные, так и негативные 
тесты могут (а иногда и обязаны) встречаться на всех перечисленных уровнях. Напри- 
мер, деление на ноль в калькуляторе явно должно относиться к дымовому тестирова- 
нию, хотя это яркий пример негативного тест-кейса. 


К сожалению, часто можно встретить мнение, что дымовое тестирование, тестирование 


Для лучшего запоминания отразим эту классификацию графически: 
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Рисунок 2.3.й — Классификация тестирования по (убыванию) степени важности 
тестируемых функций (по уровню функционального тестирования) 


145 Extended test. The idea is to develop а comprehensive application system test suite Бу modeling essential capabilities аз 
extended use cases. [By «Extended Use Case Test Design Pattern», Rob Kuijt] 
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2.3.2.7. КЛАССИФИКАЦИЯ ПО ПРИНЦИПАМ РАБОТЫ С ПРИЛОЖЕНИЕМ 


• Позитивное тестирование (positive testing!46) направлено на исследование приложения B 
ситуации, когда все действия выполняются строго по инструкции без каких бы то ни было 
ошибок, отклонений, ввода неверных данных и т.д. Если позитивные тест-кейсы заверша- 
ются ошибками, это тревожный признак — приложение работает неверно даже в идеаль- 
ных условиях (и можно предположить, что в неидеальных условиях оно работает ещё хуже). 
Для ускорения тестирования несколько позитивных тест-кейсов можно объединять (напри- 
мер, перед отправкой заполнить все поля формы верными значениями) — иногда это может 
усложнить диагностику ошибки, но существенная экономия времени компенсирует этот 
риск. 


• Негативное тестирование (negative {езНпэ147, invalid testing!48) — направлено на исследова- 
ние работы приложения в ситуациях, когда с ним выполняются (некорректные) операции 
и/или используются данные, потенциально приводящие к ошибкам (классика жанра — де- 
ление на ноль). Поскольку в реальной жизни таких ситуаций значительно больше (пользова- 
тели допускают ошибки, злоумышленники осознанно «ломают» приложение, в среде работы 
приложения возникают проблемы и т.д.), негативных тест-кейсов оказывается значительно 
больше, чем позитивных (иногда — в разы или даже на порядки). В отличие от позитивных 
негативные тест-кейсы не стоит объединять, т. к. подобное решение может привести к не- 
верной трактовке поведения приложения и пропуску (необнаружению) дефектов. 


146 Positive testing is testing process where the system validated against the valid input data. In this testing tester always 
check for only valid set of values and check if application behaves as expected with its expected inputs. The main intention of this 
testing is to check whether software application not showing error when not supposed to & showing error when supposed to. 
Such testing is to be carried out keeping positive point of view & only execute the positive scenario. Positive Testing always tries 
to prove that a given product and project always meets the requirements and specifications. [http://www.softwaretestingclass. 
com/positive-and-negative-testing-in-software-testing/] 

147 Negative testing. Tests aimed at showing that a component or system does not work. Negative testing is related to the 
testers attitude rather than a specific test approach or test design technique, e.g. testing with invalid input values or exceptions. 
[ISTQB Glossary] 


148 Invalid testing. Testing using input values that should be rejected by the component or system. [ISTQB Glossary] 
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2.3.2.8. КЛАССИФИКАЦИЯ ПО ПРИРОДЕ ПРИЛОЖЕНИЯ 


Данный вид классификации является искусственным, поскольку «внутри» речь будет идти об 
одних и тех же видах тестирования, отличающихся в данном контексте лишь концентрацией на 
соответствующих функциях и особенностях приложения, использованием специфических ин- 
струментов и отдельных техник. 


• Тестирование веб-приложений (web-applications testing) сопряжено с интенсивной Jes- 
тельностью в области тестирования совместимости 1 (в особенности — кросс-браузерно- 
го тестирования ?}), тестирования производительностий 3}, автоматизации тестирования с 
использованием широкого спектра инструментальных средств. 


• Тестирование мобильных приложений (mobile applications testing) также требует повы- 
шенного внимания к тестированию совместимости Ц, оптимизации производительно- 
сти3} (в том числе клиентской части с точки зрения снижения энергопотребления), авто- 
матизации тестирования с применением эмуляторов мобильных устройств. 


• Тестирование настольных приложений (desktop applications testing) является самым клас- 
сическим среди всех перечисленных в данной классификации, и его особенности зависят 
от предметной области приложения, нюансов архитектуры, ключевых показателей каче- 
ства и т.д. 


Эту классификацию можно продолжать очень долго. Например, можно отдельно рассмат- 
ривать тестирование консольных приложений (console applications testing) и приложений 
с графическим интерфейсом (GUl-applications testing), серверных приложений (server 
applications testing) и клиентских приложений (client applications testing) и т.д. 
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2.3.2.9. КЛАССИФИКАЦИЯ ПО ФОКУСИРОВКЕ 
НА УРОВНЕ АРХИТЕКТУРЫ ПРИЛОЖЕНИЯ 


Данный вид классификации, как и предыдущий, также является искусственным и отражает 
лишь концентрацию внимания на отдельной части приложения. 


• Тестирование уровня представления (presentation tier testing) сконцентрировано на той 
части приложения, которая отвечает за взаимодействие с «внешним миром» (как пользо- 
вателями, так и другими приложениями). Здесь исследуются вопросы удобства использо- 
вания, скорости отклика интерфейса, совместимости с браузерами, корректности работы 
интерфейсов. 


• Тестирование уровня бизнес-логики (business logic tier testing) отвечает за проверку основ- 
ного набора функций приложения и строится на базе ключевых требований к приложению, 
бизнес-правил и общей проверки функциональности. 


• Тестирование уровня данных (data tier testing) сконцентрировано на той части приложе- 
ния, которая отвечает за хранение и некоторую обработку данных (чаще всего — в базе 
данных или ином хранилище). Здесь особый интерес представляет тестирование данных, 
проверка соблюдения бизнес-правил, тестирование производительности. 


Ø Если вы не знакомы с понятием многоуровневой архитектуры приложений, ознакомь- 
тесь с ним хотя бы по материалу!“ из Википедии. 


149 «Multitier architecture», Wikipedia [http://en.wikipedia.org/wiki/Multitier_architecture] 
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2.3.2.10. КЛАССИФИКАЦИЯ ПО ПРИВЛЕЧЕНИЮ 


КОНЕЧНЫХ ПОЛЬЗОВАТЕЛЕЙ 


Все три перечисленных ниже вида тестирования ОТНОСЯТСЯ К операционному тестирова- 
нию 0. 


e Альфа-тестирование (alpha {е$Нп5150) выполняется внутри организации-разработчика с 


возможным частичным привлечением конечных пользователей. Может являться формой 
внутреннего приёмочного тестирования!89). В некоторых источниках отмечается, что это 
тестирование должно проводиться без привлечения команды разработчиков, но другие 
источники не выдвигают такого требования. Суть этого вида вкратце: продукт уже можно 
периодически показывать внешним пользователям, но он ещё достаточно «сырой», потому 
основное тестирование выполняется организацией-разработчиком. 


Бета-тестирование (beta їезїїпр!?!) выполняется вне организации-разработчика с актив- 
ным привлечением конечных пользователей/заказчиков. Может являться формой внешнего 
приёмочного тестирования. Суть этого вида вкратце: продукт уже можно открыто TOKA- 
зывать внешним пользователям, он уже достаточно стабилен, но проблемы всё ещё могут 
быть, и для их выявления нужна обратная связь от реальных пользователей. 


Гамма-тестирование (gamma ѓеѕііпо!52) — финальная стадия тестирования перед выпуском 
продукта, направленная на исправление незначительных дефектов, обнаруженных в бе- 
та-тестировании. Как правило, также выполняется с максимальным привлечением конеч- 
ных пользователей/заказчиков. Может являться формой внешнего приёмочного тестиро- 
вания!89}. Суть этого вида вкратце: продукт уже почти готов, и сейчас обратная связь от 
реальных пользователей используется для устранения последних недоработок. 


150 Alpha testing. Simulated ог actual operational testing Бу potential users/customers ог ап independent test team at the 


developers site, but outside the development organization. Alpha testing is often employed for off-the-shelf software as а form 
of internal acceptance testing. [ISTQB Glossary] 


151 Beta testing. Operational testing by potential and/or existing users/customers at an external site not otherwise involved 


with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the 
business processes. Beta testing is often employed as a form of external acceptance testing for off-the-shelf software in order to 
acquire feedback from the market. [ISTQB Glossary] 


152 Gamma testing is done when software is ready for release with specified requirements, this testing done directly by 


skipping all the in-house testing activities. The software is almost ready for final release. No feature development or enhancement 
of the software is undertaken and tightly scoped bug fixes are the only code. Gamma check is performed when the application 
is ready for release to the specified requirements and this check is performed directly without going through all the testing 
activities at home. [http://www.360logica.com/blog/2012/06/what-are-alpha-beta-and-gamma-testing.html] 
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2.3.2.11. КЛАССИФИКАЦИЯ ПО СТЕПЕНИ ФОРМАЛИЗАЦИИ 


e Тестирование на основе тест-кейсов (scripted іеѕііпо!53, test case based testing) — формали- 
зованный подход, в котором тестирование производится на основе заранее подготовленных 
тест-кейсов, наборов тест-кейсов и иной документации. Это самый распространённый спо- 
соб тестирования, который также позволяет достичь максимальной полноты исследования 
приложения за счёт строгой систематизации процесса, удобства применения метрик и ши- 
рокого набора выработанных за десятилетия и проверенных на практике рекомендаций. 


. Исследовательское тестирование (exploratory testing!’4) — частично формализованный 
подход, в рамках которого тестировщик выполняет работу с приложением по выбранному 
сценарию 48}, который, в свою очередь, дорабатывается в процессе выполнения с целью 
более полного исследования приложения. Ключевым фактором успеха при выполнении 
исследовательского тестирования является именно работа по сценарию, а не выполнение 
разрозненных бездумных операций. Существует даже специальный сценарный подход, на- 
зываемый сессионным тестированием (session-based {езНпз155). В качестве альтернативы 
сценариям при выборе действий с приложением иногда могут использоваться чек-листы, и 
тогда этот вид тестирования называют тестированием на основе чек-листов (checklist-based 
testing1>6). 


Дополнительную информацию об исследовательском тестировании можно получить 
из статьи Джеймса Баха «Что такое исследовательское тестирование? 157» 


e Свободное (интуитивное) тестирование (ad hoc ќеѕіїіпо!158) — полностью неформализо- 
ванный подход, В котором не предполагается использования ни тест-кейсов, ни чек-листов, 
НИ сценариев == тестировщик ПОЛНОСТЬЮ опирается на свой профессионализм и интуицию 
(experience-based їезїїпр!??) для спонтанного выполнения с приложением действий, KOTO- 
рые, как он считает, могут обнаружить ошибку. Этот вид тестирования используется редко 
и исключительно как дополнение к полностью или частично формализованному тестирова- 
НИЮ В случаях, когда для исследования некоторого аспекта поведения приложения (пока?) 
нет тест-кейсов. 


Zœ Ни в коем случае не стоит путать исследовательское и свободное тестирование. Это 
О разные техники исследования приложения с разной степенью формализации, разными 


задачами и областями применения. 


153 Scripted testing. Test execution carried ош by following а previously documented sequence of tests. [ISTQB Glossary] 


154 Exploratory testing. An informal test design technique where the tester actively controls the design of the tests as those 
tests are performed and uses information gained while testing to design new and better tests. [ISTQB Glossary] 


155 Session-based Testing. An approach to testing in which test activities are planned as uninterrupted sessions of test 
design and execution, often used in conjunction with exploratory testing. [ISTQB Glossary] 

156 Checklist-based Testing. An experience-based test design technique whereby the experienced tester uses a high-level 
list of items to be noted, checked, or remembered, or a set of rules or criteria against which a product has to be verified. [ISTQB 
Glossary] 


157 «What is Exploratory Testing?», James Bach [http://www.satisfice.com/articles/what_is_et.shtml] 


158 Ad hoc testing. Testing carried out informally; no formal test preparation takes place, no recognized test design 
technique is used, there are no expectations for results and arbitrariness guides the test execution activity. [ISTQB Glossary] 


159 Experience-based Testing. Testing based on the tester’s experience, knowledge and intuition. [ISTQB Glossary] 
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2.3.2.12. КЛАССИФИКАЦИЯ ПО ЦЕЛЯМ И ЗАДАЧАМ 


• Позитивное тестирование (рассмотрено ранее{83}). 
• Негативное тестирование (рассмотрено ранее{83)). 


. Функциональное тестирование (functional testing!6?) — вид тестирования, направленный 
на проверку корректности работы функциональности приложения (корректность реализа- 
ции функциональных требований 1). Часто функциональное тестирование ассоциируют 
с тестированием по методу чёрного ящика{ 3}, однако и по методу белого ящика!73) вполне 
можно проверять корректность реализации функциональности. 


(functional testing!60) и тестированием функциональности (functionality testing!6!). Под- 
робнее о функциональном тестировании можно прочесть в статье «What is Functional 
testing (Testing of functions) in software?»162, а о тестировании функциональности в CTA- 
тье «What is functionality testing in software?» 163. 


© Часто возникает вопрос, в чём разница между функциональным тестированием 


Если вкратце, то: 


• функциональное тестирование (как антоним нефункционального) направлено на 
проверку того, какие функции приложения реализованы, и что они работают вер- 
ным образом; 

• тестирование функциональности направлено на те же задачи, но акцент смещён в 
сторону исследования приложения в реальной рабочей среде, после локализации и в 
тому подобных ситуациях. 


• Нефункциональное тестирование (non-functional іеѕіїпо!64) — вид тестирования, направ- 
ленный на проверку нефункциональных особенностей приложения (корректность реали- 
зации нефункциональных требований 1), таких как удобство использования, совмести- 
мость, производительность, безопасность и т.д. 


• Инсталляционное тестирование (installation testing, installability testing!65) — тестирование, 
направленное на выявление дефектов, влияющих на протекание стадии инсталляции (уста- 
новки) приложения. В общем случае такое тестирование проверяет множество сценариев и 
аспектов работы инсталлятора в таких ситуациях, как: 


° новая среда исполнения, в которой приложение ранее не было инсталлировано; 

° обновление существующей версии («апгрейд»); 

° изменение текущей версии на более старую («даунгрейд»); 

° повторная установка приложения с целью устранения возникших проблем («пере- 
инсталляция»); 

° повторный запуск инсталляции после ошибки, приведшей к невозможности продолже- 
ния инсталляции; 


160 Functional testing. Testing Базе оп ап analysis of фе specification of the functionality of а component ог system. 
[ISTQB Glossary] 

161 Functionality testing. The process of testing to determine the functionality of a software product (the capability of 
the software product to provide functions which meet stated and implied needs when the software is used under specified 
conditions). [ISTQB Glossary] 

162 «What is Functional testing (Testing of functions) in software?» [http://istqbexamcertification.com/what-is-functional- 
testing-testing-of-functions-in-software/] 

163 «What is functionality testing in software?» [http://istqbexamcertification.com/what-is-functionality-testing-in- 
software/] 

164 Non-functional testing. Testing the attributes of a component or system that do not relate to functionality, e.g. reliability, 
efficiency, usability, maintainability and portability. [ISTQB Glossary] 

165 Installability testing. The process of testing the installability of a software product. Installability is the capability of the 
software product to be installed in a specified environment. [ISTQB Glossary] 
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° удаление приложения; 
° установка нового приложения из семейства приложений; 
° автоматическая инсталляция без участия пользователя. 


e Регрессионное тестирование (regression {е5 12166) — тестирование, направленное на про- 
верку того факта, что в ранее работоспособной функциональности не появились ошибки, 
вызванные изменениями в приложении или среде его функционирования. Фредерик Брукс 
в своей книге «Мифический человеко-месяц»!67 писал: «Фундаментальная проблема при 
сопровождении программ состоит в том, что исправление одной ошибки с большой вероят- 
ностью (20-50 %) влечёт появление новой». Потому регрессионное тестирование является 
неотъемлемым инструментом обеспечения качества и активно используется практически в 
любом проекте. 


• Повторное тестирование (ге-{е$ 415168, confirmation testing) — выполнение тест-кейсов, KO- 
торые ранее обнаружили дефекты, с целью подтверждения устранения дефектов. Фактиче- 
ски этот вид тестирования сводится к действиям на финальной стадии жизненного цикла 
отчёта о дефекте 71, направленным на то, чтобы перевести дефект в состояние «проверен» 
и «закрыт». 


e Приёмочное тестирование (acceptance їезїїпр!®?) — формализованное тестирование, Ha- 
правленное на проверку приложения с точки зрения конечного пользователя/заказчика и 
вынесения решения о том, принимает ли заказчик работу у исполнителя (проектной коман- 
ды). Можно выделить следующие подвиды приёмочного тестирования (хотя упоминают их 
крайне редко, ограничиваясь в основном общим термином «приёмочное тестирование»): 


° Производственное приёмочное тестирование (factory acceptance ќеѕііпр170) — выпол- 
няемое проектной командой исследование полноты и качества реализации приложе- 
ния с точки зрения его готовности к передаче заказчику. Этот вид тестирования часто 
рассматривается как синоним альфа-тестирования!86). 

° Операционное приёмочное тестирование (operational acceptance testing!”!, production 
acceptance testing) — операционное тестирование!90), выполняемое с точки зрения вы- 
полнения инсталляции, потребления приложением ресурсов, совместимости с про- 
граммной и аппаратной платформой ит.д. 

° Итоговое приёмочное тестирование (site acceptance ќеѕіїпо172) — тестирование конеч- 
ными пользователями (представителями заказчика) приложения в реальных условиях 
эксплуатации с целью вынесения решения о том, требует ли приложение доработок 
или может быть принято в эксплуатацию в текущем виде. 


166 Regression testing. Testing of a previously tested program following modification to ensure that defects have пої been 
introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software 
or its environment is changed. [ISTQB Glossary] 

167 Frederick Brooks, «The Mythical Man-Month». 

168 Re-testing, Confirmation testing. Testing that runs test cases that failed the last time they were run, in order to verify 
the success of corrective actions. [ISTQB Glossary] 

169 Acceptance Testing. Formal testing with respect to user needs, requirements, and business processes conducted to 
determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity 
to determine whether or not to accept the system. [ISTQB Glossary] 

170 Factory acceptance testing. Acceptance testing conducted at the site at which the product is developed and performed 
by employees of the supplier organization, to determine whether or not a component or system satisfies the requirements, 
normally including hardware as well as software. [ISTQB Glossary] 

171 Operational acceptance testing, Production acceptance testing. Operational testing in the acceptance test phase, 
typically performed in a (simulated) operational environment by operations and/or systems administration staff focusing on 
operational aspects, e.g. recoverability, resource-behavior, installability and technical compliance. [ISTQB Glossary] 

172 Site acceptance testing. Acceptance testing by users/customers at their site, to determine whether ог not a component 
or system satisfies the user/customer needs and fits within the business processes, normally including hardware as well as 
software. [ISTQB Glossary] 
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• Операционное тестирование (operational testing!”3) — тестирование, проводимое в реаль- 


ной или приближенной к реальной операционной среде (operational environment!”4), вклю- 
чающей операционную систему, системы управления базами данных, серверы приложений, 
веб-серверы, аппаратное обеспечение и т.д. 


• Тестирование удобства использования (usability!7> testing) — тестирование, направленное 


на исследование того, насколько конечному пользователю понятно, как работать с продук- 
том (understandability176, learnability177, operability178), а также на то, насколько ему нравится 
использовать продукт (attractiveness179). И это не оговорка — очень часто успех продукта 
зависит именно от эмоций, которые он вызывает у пользователей. Для эффективного прове- 
дения этого вида тестирования требуется реализовать достаточно серьёзные исследования 
с привлечением конечных пользователей, проведением маркетинговых исследований и т.д. 


терфейса пользователя (GUI testing!84) — не одно и то же! Например, корректно pabo- 


@ Важно! Тестирование удобства использования (usability!”> testing) и тестирование ин- 


тающий интерфейс может быть неудобным, а удобный может работать некорректно. 


• Тестирование доступности (accessibility testing180) — тестирование, направленное на иссле- 


дование пригодности продукта к использованию людьми с ограниченными возможностями 
(слабым зрением и т.д.) 


e Тестирование интерфейса (interface testing!8!) — тестирование, направленное на провер- 


ку интерфейсов приложения или его компонентов. По определению 15ТОВ-глоссария этот 
вид тестирования относится к интеграционному тестированиюі77), и это вполне справед- 
ливо для таких его вариаций как тестирование интерфейса прикладного программирова- 
ния (АРІ їеѕііпр!82) и интерфейса командной строки (СІЛ testing!83), хотя последнее может 
выступать и как разновидность тестирования пользовательского интерфейса, если через 
командную строку с приложением взаимодействует пользователь, а не другое приложение. 
Однако многие источники предлагают включить в состав тестирования интерфейса и тести- 
рование непосредственно интерфейса пользователя (GUI testing!84). 


173 Operational testing. Testing conducted to evaluate а component ог system in Из operational environment. [ISTQB 
Glossary] 


174 Operational environment. Hardware and software products installed at users’ or customers’ sites where the component 
or system under test will be used. The software may include operating systems, database management systems, and other 
applications. [ISTQB Glossary] 

175 Usability. The capability of the software to be understood, learned, used and attractive to the user when used under 
specified conditions. [ISTQB Glossary] 

176 Understandability. The capability of the software product to enable the user to understand whether the software is 
suitable, and how it can be used for particular tasks and conditions of use. [ISTQB Glossary] 


177 Learnability. The capability of the software product to enable the user to learn its application. [ISTQB Glossary] 

178 Operability. The capability of the software product to enable the user to operate and control it. [ISTQB Glossary] 

179 Attractiveness. The capability of the software product to be attractive to the user. [ISTQB Glossary] 

180 Accessibility testing. Testing to determine the ease by which users with disabilities can use a component or system. 
[ISTQB Glossary] 

181 Interface Testing. An integration test type that is concerned with testing the interfaces between components or systems. 
[ISTQB Glossary] 

182 API testing. Testing performed by submitting commands to the software under test using programming interfaces of 
the application directly. [ISTQB Glossary] 

183 CLI testing. Testing performed by submitting commands to the software under test using a dedicated command-line 
interface. [ISTQB Glossary] 

184 GUI testing. Testing performed by interacting with the software under test via the graphical user interface. [ISTQB 
Glossary] 
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2 Важно! Тестирование интерфейса пользователя (GUI {е5 15184) и тестирование удоб- 
@ ства использования (usability!7> testing) — не одно и то же! Например, удобный интер- 
фейс может работать некорректно, а корректно работающий интерфейс может быть 


неудобным. 


• Тестирование безопасности (security {е$Нп5185) — тестирование, направленное на проверку 
способности приложения противостоять злонамеренным попыткам получения доступа K 
данным или функциям, права на доступ к которым у злоумышленника нет. 


С =) Подробнее про этот вид тестирования можно почитать в статье «What is Security testing 
in software testing?»186, 


• Тестирование интернационализации (internationalization testing, 118п testing, globalization187 
testing, localizability!88 testing) — тестирование, направленное на проверку готовности про- 
дукта к работе с использованием различных языков и с учётом различных национальных 
и культурных особенностей. Этот вид тестирования не подразумевает проверки качества 
соответствующей адаптации (этим занимается тестирование локализации, см. следующий 
пункт), оно сфокусировано именно на проверке возможности такой адаптации (например: 
что будет, если открыть файл с иероглифом в имени; как будет работать интерфейс, если всё 
перевести на японский; может ли приложение искать данные в тексте на корейском и т.д.). 


• Тестирование локализации (localization testing!39, 1101) — тестирование, направленное на 
проверку корректности и качества адаптации продукта к использованию на том или ином 
языке с учётом национальных и культурных особенностей. Это тестирование следует за тес- 
тированием интернационализации (см. предыдущий пункт) и проверяет корректность пе- 
ревода и адаптации продукта, а не готовность продукта к таким действиям. 


• Тестирование совместимости (compatibility testing, interoperability testing!?0) — тестирова- 
ние, направленное на проверку способности приложения работать в указанном окружении. 
Здесь, например, может проверяться: 


° Совместимость с аппаратной платформой, операционной системой и сетевой инфра- 
структурой (конфигурационное тестирование, configuration testing!’!). 


185 Security testing. Testing to determine the security of the software product. [ISTQB Glossary] 

186 «What is Security testing in software testing?» [http://istqbexamcertification.com/what-is-security-testing-in-software/] 

187 Globalization. The process of developing a program core whose features and code design are not solely based on a single 
language or locale. Instead, their design is developed for the input, display, and output of a defined set of Unicode-supported 
language scripts and data related to specific locales. [«Globalization Step-by-Step», https://msdn.microsoft.com/en-us/goglobal/ 
bb688112] 

188 Localizability. The design of the software code base and resources such that a program can be localized into different 
language editions without any changes to the source code. [«Globalization Step-by-Step», https://msdn.microsoft.com/en-us/ 
goglobal/bb688112] 

189 Localization testing checks the quality of a product’ localization for a particular target culture/locale. This test is based 
on the results of globalization testing, which verifies the functional support for that particular culture/locale. Localization 
testing can be executed only on the localized version of a product. [«Localization Testing», https://msdn.microsoft.com/en-us/ 
library/aa292138%28v=vs.71%29.aspx] 

190 Compatibility Testing, Interoperability Testing. The process of testing to determine the interoperability of a software 
product (the capability to interact with one or more specified components or systems). [ISTQB Glossary] 

191 Configuration Testing, Portability Testing. The process of testing to determine the portability of a software product 
(the ease with which the software product can be transferred from one hardware or software environment to another). [ISTQB 
Glossary] 
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° Совместимость с браузерами и их версиями (кросс-браузерное тестирование, сгоѕѕ- 
browser testing!?2). (См. также тестирование веб-приложений 4}). 

° Совместимость с мобильными устройствами (mobile testing!?3). (См. также тестирова- 
ние мобильных приложений!84)). 

° И так далее. 


В некоторых источниках к тестированию совместимости добавляют (хоть и подчёркивая, 
что это — не его часть) т.н. тестирование соответствия (compliance testing!’4, conformance 
testing, regulation testing). 


\ 
| 
| 


< Рекомендуется ознакомиться с дополнительным материалом по тестированию CO- 
вместимости с мобильными платформами в статьях «What is Mobile Тезїпр?»!? и 
«Beginner’s Guide to Mobile Application Теѕіїпо» 196. 


e Тестирование данных (data quality!97 testing) и баз данных (database integrity testing!98) — 
два близких по смыслу вида тестирования, направленных на исследование таких характе- 
ристик данных, как полнота, непротиворечивость, целостность, структурированность ит.д. 
В контексте баз данных исследованию может подвергаться адекватность модели предметной 
области, способность модели обеспечивать целостность и консистентность данных, кор- 
ректность работы триггеров, хранимых процедур ит.д. 


• Тестирование использования ресурсов (resource utilization ќеѕііпр!99, efficiency їезїїпр?®00, 
storage testing??!) — совокупность видов тестирования, проверяющих эффективность NC- 
пользования приложением доступных ему ресурсов и зависимость результатов работы при- 
ложения от количества доступных ему ресурсов. Часто эти виды тестирования прямо или 


косвенно примыкают к техникам тестирования производительности!3}. 


192 Cross-browser testing helps you ensure that your web site ог web application functions correctly in various web 
browsers. Typically, QA engineers create individual tests for each browser or create tests that use lots of conditional statements 
that check the browser type used and execute browser-specific commands. [http://support.smartbear.com/viewarticle/55299/] 

193 Mobile testing is a testing with multiple operating systems (and different versions of each OS, especially with Android), 
multiple devices (different makes and models of phones, tablets, phablets), multiple carriers (including international ones), 
multiple speeds of data transference (3G, LTE, Wi-Fi), multiple screen sizes (and resolutions and aspect ratios), multiple input 
controls (including BlackBerry’s eternal physical keypads), and multiple technologies — GPS, accelerometers — that web and 
desktop apps almost never use. [http://smartbear.com/all-resources/articles/what-is-mobile-testing/] 

194 Compliance testing, Conformance testing, Regulation testing. The process of testing to determine the compliance of 
the component or system (the capability to adhere to standards, conventions or regulations in laws and similar prescriptions). 
[ISTQB Glossary] 

195 «What is Mobile Testing?» [http://smartbear.com/all-resources/articles/what-is-mobile-testing/] 

196 «Beginners Guide to Mobile Application Testing» [http://www.softwaretestinghelp.com/beginners-guide-to-mobile- 
application-testing/] 

197 Data quality. An attribute of data that indicates correctness with respect to some pre-defined criteria, e.g., business 
expectations, requirements on data integrity, data consistency. [ISTQB Glossary] 

198 Database integrity testing. Testing the methods and processes used to access and manage the data(base), to ensure 
access methods, processes and data rules function as expected and that during access to the database, data is not corrupted or 
unexpectedly deleted, updated or created. [ISTQB Glossary] 

199 Resource utilization testing, Storage testing. The process of testing to determine the resource-utilization of a software 
product. [ISTQB Glossary] 

200 Efficiency testing. The process of testing to determine the efficiency of a software product (the capability of a process to 
produce the intended outcome, relative to the amount of resources used). [ISTQB Glossary] 

201 Storage testing. This is a determination of whether or not certain processing conditions use more storage (memory) 
than estimated. [«Software Testing Concepts And Tools», Nageshwar Као Pusuluri] 
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e Сравнительное тестирование (comparison testing???) — тестирование, направленное на 
сравнительный анализ преимуществ и недостатков разрабатываемого продукта по отноше- 
нию кего основным конкурентам. 


• Демонстрационное тестирование (qualification testing???) — формальный процесс демон- 
страции заказчику продукта с целью подтверждения, что продукт соответствует всем за- 
явленным требованиям. В отличие от приёмочного тестирования! этот процесс более 
строгий и всеобъемлющий, но может проводиться и на промежуточных стадиях разработки 


продукта. 


e Избыточное тестирование (exhaustive testing??4) — тестирование приложения со всеми 
возможными комбинациями всех возможных входных данных во всех возможных условиях 
выполнения. Для сколь бы то ни было сложной системы нереализуемо, но может приме- 
няться для проверки отдельных крайне простых компонентов. 


• Тестирование надёжности (reliability testing??5) — тестирование способности приложения 
выполнять свои функции в заданных условиях на протяжении заданного времени или за- 
данного количества операций. 


e Тестирование восстанавливаемости (recoverability testing?06) — тестирование способно- 
сти приложения восстанавливать свои функции и заданный уровень производительности, 
а также восстанавливать данные в случае возникновения критической ситуации, приводя- 


щей к временной (частичной) утрате работоспособности приложения. 


e Тестирование отказоустойчивости (failover їезїїпр?07) — тестирование, заключающееся в 
эмуляции или реальном создании критических ситуаций с целью проверки способности 
приложения задействовать соответствующие механизмы, предотвращающие нарушение 
работоспособности, производительности и повреждения данных. 


• Тестирование производительности (performance ќеѕііпр208) — исследование показателей 
скорости реакции приложения на внешние воздействия при различной по характеру и ин- 
тенсивности нагрузке. В рамках тестирования производительности выделяют следующие 
подвиды: 


202 Comparison testing. Testing that compares software weaknesses and strengths to those of competitors products. 
[«Software Testing and Quality Assurance», Jyoti J. Malhotra, Bhavana S. Tiple] 

203 Qualification testing. Formal testing, usually conducted by the developer for the consumer, to demonstrate that the 
software meets its specified requirements. [«Software Testing Concepts And Tools», Nageshwar Као Pusuluri] 

204 Exhaustive testing. A test approach in which the test suite comprises all combinations of input values and preconditions. 
[ISTQB Glossary] 

205 Reliability Testing. The process of testing to determine the reliability of a software product (the ability of the software 
product to perform its required functions under stated conditions for a specified period of time, or for a specified number of 
operations). [ISTQB Glossary] 

206 Recoverability Testing. The process of testing to determine the recoverability of a software product (the capability of 
the software product to re-establish a specified level of performance and recover the data directly affected in case of failure). 
[ISTQB Glossary] 

207 Failover Testing. Testing by simulating failure modes or actually causing failures in a controlled environment. Following 
a failure, the failover mechanism is tested to ensure that data is not lost or corrupted and that any agreed service levels are 
maintained (e.g., function availability or response times). [ISTQB Glossary] 

208 Performance Testing. The process of testing to determine the performance of a software product. [ISTQB Glossary] 
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° Нагрузочное тестирование (load {е5 15209, capacity testing?!) — исследование способ- 
ности приложения сохранять заданные показатели качества при нагрузке в допустимых 
пределах и некотором превышении этих пределов (определение «запаса прочности»). 

° Тестирование масштабируемости (scalability testing?!!) — исследование способности 
приложения увеличивать показатели производительности в соответствии с увеличени- 
ем количества доступных приложению ресурсов. 

° Объёмное тестирование (volume testing?!?) — исследование производительности при- 
ложения при обработке различных (как правило, больших) объёмов данных. 

° Стрессовое тестирование (stress іеѕ(їпо213) — исследование поведения приложения при 
нештатных изменениях нагрузки, значительно превышающих расчётный уровень, или 
в ситуациях недоступности значительной части необходимых приложению ресурсов. 
Стрессовое тестирование может выполняться и вне контекста нагрузочного тестиро- 
вания: тогда оно, как правило, называется «тестированием на разрушение» (destructive 
(еѕ1п9214) и представляет собой крайнюю форму негативного тестирования{3}. 

° Конкурентное тестирование (concurrency ќеѕіїпо215) — исследование поведения при- 
ложения в ситуации, когда ему приходится обрабатывать большое количество одновре- 
менно поступающих запросов, что вызывает конкуренцию между запросами за ресур- 
сы (базу данных, память, канал передачи данных, дисковую подсистему и т.д.) Иногда 
под конкурентным тестированием понимают также исследование работы многопоточ- 
ных приложений и корректность синхронизации действий, производимых в разных 
потоках. 


В качестве отдельных или вспомогательных техник в рамках тестирования производи- 
тельности могут использоваться тестирование использования ресурсові2), тестирование 
надёжности 3}, тестирование восстанавливаемостий3}, тестирование отказоустойчиво- 
сти3} и т.д. 


р“ Подробное рассмотрение нескольких видов тестирования производительности приве- 
© дено в статье «Автоматизация тестирования производительности: основные положе- 


ния и области применения»?16. 


209 Load Testing. A type of performance testing conducted to evaluate the behavior of а component ог system with 
increasing load, e.g. numbers of parallel users and/or numbers of transactions, to determine what load can be handled by the 
component or system. [ISTQB Glossary] 

210 Capacity Testing. Testing to determine how many users and/or transactions a given system will support and still meet 
performance goals. [https://msdn.microsoft.com/en-us/library/bb924357.aspx] 

211 Scalability Testing. Testing to determine the scalability of the software product (the capability of the software product 
to be upgraded to accommodate increased loads). [ISTQB Glossary] 

212 Volume Testing. Testing where the system is subjected to large volumes of data. [ISTQB Glossary] 

213 Stress testing. A type of performance testing conducted to evaluate a system or component at or beyond the limits of 
its anticipated or specified workloads, or with reduced availability of resources such as access to memory or servers. [ISTQB 
Glossary] 

214 Destructive software testing assures proper or predictable software behavior when the software is subject to improper 
usage or improper input, attempts to crash a software product, tries to crack or break a software product, checks the robustness 
ofa software product. [«Towards Destructive Software Testing», Kiumi Akingbehin] 

215 Concurrency testing. Testing to determine how the occurrence of two or more activities within the same interval 
of time, achieved either by interleaving the activities or by simultaneous execution, is handled by the component or system. 
[ISTQB Glossary] 

216 «Автоматизация тестирования производительности: основные положения и области применения» [http:// 
svyatoslav.biz/technologies/performance_testing/] 
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2.3.2.13. КЛАССИФИКАЦИЯ ПО ТЕХНИКАМ И ПОДХОДАМ 


. Позитивное тестирование (рассмотрено ранее!83}). 
e Негативное тестирование (рассмотрено ранее! 83)). 


° Тестирование на основе опыта тестировщика, сценариев, чек-листов: 


° Исследовательское тестирование (рассмотрено ранее”). 
° Свободное (интуитивное) тестирование (рассмотрено ранее!87)). 


e Классификация по степени вмешательства в работу приложения: 


° Инвазивное тестирование (intrusive testing?!) — тестирование, выполнение KOTOPO- 
го может повлиять на функционирование приложения в силу работы инструментов 
тестирования (например, будут искажены показатели производительности) или в силу 
вмешательства (level of іпігиѕіоп218) в сам код приложения (например, для анализа pa- 
боты приложения было добавлено дополнительное протоколирование, включён вывод 
отладочной информации и т.д.) Некоторые источники рассматривают?1? инвазивное 
тестирование как форму негативного!83) или даже стрессового%} тестирования. 


° Неинвазивное тестирование (nonintrusive testing???) — тестирование, выполнение KO- 
торого незаметно для приложения и не влияет на процесс его обычной работы. 


° Классификация по техникам автоматизации: 


° Тестирование под управлением данными (data-driven testing??!) — способ разработки 
автоматизированных тест-кейсов, в котором входные данные и ожидаемые результаты 
выносятся за пределы тест-кейса и хранятся вне его — в файле, базе данных и т. д. 

° Тестирование под управлением ключевыми словами (keyword-driven testing???) — 
способ разработки автоматизированных тест-кейсов, в котором за пределы тест-кейса 
выносится не только набор входных данных и ожидаемых результатов, но и логика по- 
ведения тест-кейса, которая описывается ключевыми словами (командами). 

° Тестирование под управлением поведением (behavior-driven testing??3) — способ раз- 
работки автоматизированных тест-кейсов, в котором основное внимание уделяется 
корректности работы бизнес-сценариев, а не отдельным деталям функционирования 
приложения. 


217 Intrusive testing. Testing that collects timing and processing information during program execution that may change 
the behavior of the software from its behavior in a real environment. Intrusive testing usually involves additional code embedded 
in the software being tested or additional processes running concurrently with software being tested on the same processor. 
[http://encyclopedia2.thefreedictionary.com/intrusive+testing] 

218 Level of intrusion. The level to which a test object is modified by adjusting it for testability. [ISTQB Glossary] 

219 Intrusive testing can be considered a type of interrupt testing, which is used to test how well a system reacts to intrusions 
and interrupts to its normal workflow. [http://www.techopedia.com/definition/7802/intrusive-testing] 

220 Nonintrusive Testing. Testing that is transparent to the software under test, i.e., does not change its timing or processing 
characteristics. Nonintrusive testing usually involves additional hardware that collects timing or processing information and 
processes that information on another platform. [http://encyclopedia2.thefreedictionary.com/nonintrusive+testing] 

221 Data-driven Testing (DDT). A scripting technique that stores test input and expected results in a table or spreadsheet, 
so that a single control script can execute all of the tests in the table. Data-driven testing is often used to support the application 
of test execution tools such as capture/playback tools. [ISTQB Glossary] 

222 Keyword-driven Testing (KDT). A scripting technique that uses data files to contain not only test data and expected 
results, but also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that 
are called by the control script or the test. [ISTQB Glossary] 

223 Behavior-driven Testing (BDT). Behavior-driven Tests focuses on the behavior rather than the technical implementation 
of the software. If you want to emphasize on business point of view and requirements then BDT is the way to go. BDT are 
Given-when-then style tests written in natural language which are easily understandable to non-technical individuals. Hence 
these tests allow business analysts and management people to actively participate in test creation and review process. [Jyothi 
Rangaiah, http://www.womentesters.com/behaviour-driven-testing-an-introduction/] 
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e Классификация на основе (знания) источников ошибок: 


° Тестирование предугадыванием ошибок (error guessing??4) — техника тестирования, 
в которой тесты разрабатываются на основе опыта тестировщика и его знаний о том, 
какие дефекты типичны для тех или иных компонентов или областей функционально- 
сти приложения. Может комбинироваться с техникой т.н. «ошибкоориентированного» 
тестирования (failure-directed testing??5), в котором новые тесты строятся на основе MH- 
формации о ранее обнаруженных в приложении проблемах. 

° Эвристическая оценка (heuristic evaluation??6) — техника тестирования удобства NC- 
пользования}, направленная на поиск проблем в интерфейсе пользователя, пред- 
ставляющих собой отклонение от общепринятых норм. 

° Мутационное тестирование (mutation testing???) — техника тестирования, в которой 
сравнивается поведение нескольких версий одного и того же компонента, причём часть 
таких версий может быть специально разработана с добавлением ошибок (что позво- 
ляет оценить эффективность тест-кейсов — качественные тесты обнаружат эти специ- 
ально добавленные ошибки). Может комбинироваться со следующим в этом списке 
видом тестирования (тестированием добавлением ошибок). 

° Тестирование добавлением ошибок (error ѕеейіпо228) — техника тестирования, B KO- 
торой в приложение специально добавляются заранее известные, специально проду- 
манные ошибки с целью мониторинга их обнаружения и устранения и, таким образом, 
формирования более точной оценки показателей процесса тестирования. Может ком- 
бинироваться с предыдущим в этом списке видом тестирования (мутационным тести- 
рованием). 


e Классификация на основе выбора входных данных: 


° Тестирование на основе классов эквивалентности (equivalence partitioning???) — rex- 
ника тестирования, направленная на сокращение количества разрабатываемых и вы- 
полняемых тест-кейсов при сохранении достаточного тестового покрытия. Суть тех- 
ники состоит в выявлении наборов эквивалентных тест-кейсов (каждый из которых 
проверяет одно и то же поведение приложения) и выборе из таких наборов небольшого 
подмножества тест-кейсов, с наибольшей вероятностью обнаруживающих проблему. 

° Тестирование на основе граничных условий (boundary value analysis?30) — инстру- 
ментальная техника тестирования на основе классов эквивалентности, позволяющая 
выявить специфические значения исследуемых параметров, относящиеся к границам 
классов эквивалентности. Эта техника значительно упрощает выявление наборов эк- 
вивалентных тест-кейсов и выбор таких тест-кейсов, которые обнаружат проблему с 
наибольшей вероятностью. 


224 Error Guessing. А test design technique where the experience of the tester is used to anticipate what defects might be 
present in the component or system under test as a result of errors made, and to design tests specifically to expose them. [ISTQB 
Glossary] 

225 Failure-directed Testing. Software testing based on the knowledge of the types of errors made in the past that are likely 
for the system under test. [http://dictionary.reference.com/browse/failure-directed+testing]. 

226 Heuristic Evaluation. A usability review technique that targets usability problems in the user interface or user interface 
design. With this technique, the reviewers examine the interface and judge its compliance with recognized usability principles 
(the «heuristics»). [ISTQB Glossary] 

227 Mutation Testing, Back-to-Back Testing. Testing in which two or more variants ofa component or system are executed 
with the same inputs, the outputs compared, and analyzed in cases of discrepancies. [ISTQB Glossary] 

228 Error seeding. The process of intentionally adding known faults to those already in a computer program for the purpose 
of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program. [ISTQB 
Glossary] 

229 Equivalence partitioning. A black box test design technique in which test cases are designed to execute representatives 
from equivalence partitions. In principle test cases are designed to cover each partition at least once. [ISTQB Glossary] 

230 Boundary value analysis. A black box test design technique in which test cases are designed based on boundary values 
(input values ог output values which аге on the edge ofan equivalence partition or at the smallest incremental distance on either 
side of an edge, for example the minimum or maximum value of a range). [ISTQB Glossary] 
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° Доменное тестирование (domain апа]уѕі523!, domain testing) — техника тестирования 
на основе классов эквивалентности и граничных условий, позволяющая эффективно 
создавать тест-кейсы, затрагивающие несколько параметров (переменных) одновре- 
менно (в том числес учётом взаимозависимости этих параметров). Данная техника так- 
же описывает подходы к выбору минимального множества показательных тест-кейсов 
из всего набора возможных тест-кейсов. 

° Попарное тестирование (pairwise testing?ô?) — техника тестирования, в которой 
тест-кейсы строятся по принципу проверки пар значений параметров (переменных) 
вместо того, чтобы пытаться проверить все возможные комбинации всех значений всех 
параметров. Эта техника является частным случаем М-комбинационного тестирования 
(n-wise testing?33) и позволяет существенно сократить трудозатраты на тестирование 
(а иногда и вовсе сделать возможным тестирование в случае, когда количество «всех 
комбинаций всех значений всех параметров» измеряется миллиардами). 


F Попарное тестирование (pairwise testing?3?) — это НЕ парное тестирование (pair 
testing?34)! 


° Тестирование на основе ортогональных массивов (orthogonal array testing?35) — ин- 
струментальная техника попарного и М№-комбинационного тестирования, основанная 
на использовании т.н. «ортогональных массивов» (двумерных массивов, обладающих 
следующим свойством: если взять две любые колонки такого массива, то получивший- 
ся «подмассив» будет содержать все возможные попарные комбинации значений, пред- 
ставленных в исходном массиве). 


Ортогональные массивы — это НЕ ортогональные матрицы. Это совершенно раз- 
ные понятия! Сравните их описания в статьях «Orthogonal аггау»236 и «Orthogonal 
matrix»?37, 


Также см. комбинаторные техники тестирования 09}, которые расширяют и дополня- 
ют только что рассмотренный список видов тестирования на основе выбора входных 
данных. 


классификации, можно найти в книге Ли Коупленда «Практическое руководство 
по разработке тестов» (Тее Copeland, «А Practitioner’s Guide to Software Test Design»), 
в частности: 


© Крайне подробное описание некоторых видов тестирования, относящихся к данной 


» Тестирование на основе классов эквивалентности — в главе 3. 

» Тестирование на основе граничных условий — в главе 4. 

• Доменное тестирование — в главе 8. 

• Попарное тестирование и тестирование на основе ортогональных массивов — 
в главе 6. 


231 Domain analysis. А black box test design technique that is used to identify efficient апа effective test cases when 
multiple variables can or should be tested together. It builds on and generalizes equivalence partitioning and boundary values 
analysis. [ISTQB Glossary] 

232 Pairwise testing. A black box test design technique in which test cases are designed to execute all possible discrete 
combinations of each pair of input parameters. [ISTQB Glossary] 

233 N-wise testing. A black box test design technique in which test cases are designed to execute all possible discrete 
combinations of any set of n input parameters. [ISTQB Glossary] 

234 Pair testing. Two persons, e.g. two testers, a developer and a tester, or an end-user and a tester, working together to find 
defects. Typically, they share one computer and trade control of it while testing. [ISTQB Glossary] 

235 Orthogonal array testing. A systematic way of testing all-pair combinations of variables using orthogonal arrays. It 
significantly reduces the number of all combinations of variables to test all pair combinations. See also combinatorial testing, 
n-wise testing, pairwise testing. [ISTQB Glossary] 

236 «Orthogonal array», Wikipedia. [http://en.wikipedia.org/wiki/Orthogonal_array] 

237 «Orthogonal matrix», Wikipedia. [http://en.wikipedia.org/wiki/Orthogonal_matrix] 
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Важно! Большинство этих техник входит в «джентльменский набор любого тестиров- 
щика», потому их понимание и умение применять можно считать обязательным. 


° Классификация на основе среды выполнения: 


° Тестирование в процессе разработки (development їезїїпр?58) — тестирование, выпол- 
няемое непосредственно в процессе разработки приложения и/или в среде выполне- 
ния, отличной от среды реального использования приложения. Как правило, ВЫПОЛНЯ- 
ется самими разработчиками. 

° Операционное тестирование (рассмотрено ранее °}). 


• Тестирование на основе кода (code based testing). В различных источниках эту технику Ha- 
зывают по-разному (чаще всего — тестированием на основе структур, причём некоторые 
авторы смешивают в один набор тестирование по потоку управления и по потоку данных, 
а некоторые строго разделяют эти стратегии). Подвиды этой техники также организуют в 
разные комбинации, но наиболее универсально их можно классифицировать так: 


° Тестирование по потоку управления (control flow testing?3?) — семейство техник Tec- 
тирования, в которых тест-кейсы разрабатываются с целью активации и проверки 
выполнения различных последовательностей событий, которые определяются посред- 
ством анализа исходного кода приложения. Дополнительное подробное пояснение 
см. дальше в этом разделе (см. тестирование на основе структур кода9}). 

° Тестирование по потоку данных (data-flow testing?40) — семейство техник тестиро- 
вания, основанных на выборе отдельных путей из потока управления с целью иссле- 
дования событий, связанных с изменением состояния переменных. Дополнительное 
подробное пояснение см. дальше в этом разделе (в части, где тестирование по потоку 
данных пояснено с точки зрения стандарта 1ЗОЛЕСЛЕЕЕ 29119-4110}). 

° Тестирование по диаграмме или таблице состояний (state transition testing?t!) — rex- 
ника тестирования, в которой тест-кейсы разрабатываются для проверки переходов 
приложения из одного состояния в другое. Состояния могут быть описаны диаграммой 
состояний (state diagram?4?) или таблицей состояний (state table?43). 


СЕ) хорошее подробное пояснение по данному виду тестирования можно прочесть в CTA- 
тье «What is State transition testing in software testing?»?44, 


Иногда эту технику тестирования также называют «тестированием по принципу KO- 
нечного автомата» (finite state тасһіпе245 testing). Важным преимуществом этой TeX- 


238 Development testing. Formal ог informal testing conducted during the implementation of а component ог system, 
usually in the development environment by developers. [ISTQB Glossary] 

239 Control Flow Testing. An approach to structure-based testing in which test cases are designed to execute specific 
sequences of events. Various techniques exist for control flow testing, e.g., decision testing, condition testing, and path testing, 
that each have their specific approach and level of control flow coverage. [ISTQB Glossary] 

240 Data Flow Testing. A white box test design technique in which test cases are designed to execute definition-use pairs of 
variables. [ISTQB Glossary] 

241 State Transition Testing. A black box test design technique in which test cases are designed to execute valid and invalid 
state transitions. [ISTQB Glossary] 

242 State Diagram. A diagram that depicts the states that a component or system can assume, and shows the events or 
circumstances that cause and/or result from a change from one state to another. [ISTQB Glossary] 

243 State Table. A grid showing the resulting transitions for each state combined with each possible event, showing both 
valid and invalid transitions. [ISTQB Glossary] 

244 «What is State transition testing in software testing?» [http://istqbexamcertification.com/what-is-state-transition- 
testing-in-software-testing/] 

245 Finite State Machine. A computational model consisting of a finite number of states and transitions between those 
states, possibly with accompanying actions. [ISTQB Glossary] 
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ники является возможность применения в ней теории конечных автоматов (которая 
хорошо формализована), а также возможность использования автоматизации для ге- 
нерации комбинаций входных данных. 


° Инспекция (аудит) кода (code review, code inspection?46) — семейство техник повыше- 
ния качества кода за счёт ТОГО, ЧТО В процессе создания или совершенствования кода 
участвуют несколько человек. Степень формализации аудита кода может варьировать- 
ся от достаточно беглого просмотра до тщательной формальной инспекции. В отличие 
от техник статического анализа кода (по потоку управления и потоку данных) аудит 
кода также улучшает такие его характеристики, как понятность, поддерживаемость, 
соответствие соглашениям об оформлении и т.д. Аудит кода выполняется в основном 
самими программистами. 


e Тестирование на основе структур кода (structure-based techniques) предполагает возмож- 
ность исследования логики выполнения кода в зависимости от различных ситуаций И ВКЛЮ- 
чает в себя: 


° Тестирование на основе выражений (statement testing?47) — техника тестирования 
(по методу белого ящика), в которой проверяется корректность (и сам факт) выполне- 
ния отдельных выражений в коде. 

° Тестирование на основе ветвей (branch {ез 15248) — техника тестирования (по методу 
белого ящика), в которой проверяется выполнение отдельных ветвей кода (под ветвью 
понимается атомарная часть кода, выполнение которой происходит или не происходит 
в зависимости от истинности или ложности некоторого условия). 

° Тестирование на основе условий (condition їезїпр?#9) — техника тестирования (по Me- 
тоду белого ящика), в которой проверяется выполнение отдельных условий (услови- 
ем считается выражение, которое может быть вычислено до значения «истина» или 
«ложь»). 

° Тестирование на основе комбинаций условий (multiple condition testing?50) — техника 
тестирования (по методу белого ящика), в которой проверяется выполнение сложных 
(составных) условий. 

о Тестирование на основе отдельных условий, порождающих ветвление («решающих 
условий») (modified condition decision coverage testing?!) — техника тестирования 
(по методу белого ящика), в которой проверяется выполнение таких отдельных усло- 
вий в составе сложных условий, которые в одиночку определяют результат вычисления 
всего сложного условия. 

° Тестирование на основе решений (decision testing???) — техника тестирования (по Me- 
тоду белого ящика), в которой проверяется выполнение сложных ветвлений (с двумя 


246 Inspection. А type of peer review that relies оп visual examination of documents to detect defects, e.g. violations of 
development standards and non-conformance to higher level documentation. The most formal review technique and therefore 
always based on a documented procedure. [ISTQB Glossary] 

247 Statement Testing. A white box test design technique in which test cases are designed to execute statements (statement 
is an entity in a programming language, which is typically the smallest indivisible unit of execution). [ISTQB Glossary] 

248 Branch Testing. A white box test design technique in which test cases are designed to execute branches (branch is a basic 
block that can be selected for execution based on a program construct in which one of two or more alternative program paths is 
available, e.g. case, jump, go to, if-then-else.). [ISTQB Glossary] 

249 Condition Testing. A white box test design technique in which test cases are designed to execute condition outcomes 
(condition is a logical expression that can be evaluated as True or False, e.g. A > B). [ISTQB Glossary] 

250 Multiple Condition Testing. A white box test design technique in which test cases are designed to execute combinations 
of single condition outcomes (within one statement). [ISTQB Glossary] 

251 Modified Condition Decision Coverage Testing. Technique to design test cases to execute branch condition outcomes 
that independently affect a decision outcome and discard conditions that do not affect the final outcome. [«Guide to Advanced 
Software Testing, Second Edition», Anne Mette Hass]. 

252 Decision Testing. A white box test design technique in which test cases are designed to execute decision outcomes 
(decision is program point at which the control flow has two or more alternative routes, e.g. a node with two or more links to 
separate branches). [ISTQB Glossary] 
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и более возможными вариантами). Несмотря на то что «два варианта» сюда также под- 
ходит, формально такую ситуацию стоит отнести к тестированию на основе условий. 

° Тестирование на основе путей (path testing?>3) — техника тестирования (по методу 
белого ящика), в которой проверяется выполнение всех или некоторых специально вы- 
бранных путей в коде приложения. 


основе структур кода должны звучать чуть-чуть иначе, т.к. в программировании ус- 
ловием считается выражение без логических операторов, а решением — выражение 
с логическими операторами. Но глоссарий ISTQB не делает на этом акцента, а потому 
приведённые выше определения можно считать корректными. Однако, если вам инте- 
ресно, рекомендуется ознакомиться с заметкой «What is the difference between а Decision 
and а Сопййоп?»2?°“, 


Ө Если говорить строго научно, то определения большинства видов тестирования на 


Кратко вся суть видов тестирования на основе структур кода и их отличия показаны в таб- 


лице 2.3.с. 
Таблица 2.3.с — Виды тестирования на основе структур кода 
Русскоязычное Англоязычное 
Суть (что проверяется) 

название название 
Тестирование Отдельные атомарные участки кода, наприме 

P „ | Statement testing n аА СИРЕ 
на основе выражений х= 10 
Тестирование i 

Branch testing Проход по ветвям выполнения кода. 


на основе ветвей 


Condition testing, 


Тестирование че 
Р Branch Condition 


Отдельные условные конструкции, например 


на основе условий | Ш(а==Ъ) 
и Testing 
Multiple condition 
Тестирование testin С 
1 оставные условные конструкции, наприме 
на основе & y рукции, например 


Branch Condition if ((a == b) || (c == d)) 


комбинаций условий Е . 
ции у Combination Testing 


Отдельные условия, в одиночку влияющие 

на итог вычисления составного условия, 
Modified Condition |например в условии if ((х == у) && (п == m)) 
Decision Coverage |ложное значение в каждом из отдельных усло- 
Testing вий само по себе приводит к результату false 
вне зависимости от результата вычисления 


Тестирование 

на основе отдельных 
условий, порождаю- 
щих ветвление 
(«решающих 


условий») 
второго условия 
Тестирование =. Сложные ветвления, например операто 
P |Decision testing | ‚например оператор 
на основе решений switch 
Тестирование : 
Path testing Все или специально выбранные пути 


на основе путей 


253 Path testing. А white box test design technique in which test cases are designed to execute paths. [ISTQB Glossary] 


254 «What is the difference between a Decision and a Condition?» [http://www-01.ibm.com/support/docview. 
wss?uid=swg21129252] 
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• Тестирование на основе (моделей) поведения приложения (application behavior/model-based 
testing): 


° Тестирование по таблице принятия решений (decision table testing?) — техника 
тестирования (по методу чёрного ящика), в которой тест-кейсы разрабатываются на 
основе т.н. таблицы принятия решений, в которой отражены входные данные (и их 
комбинации) и воздействия на приложение, а также соответствующие им выходные 
данные и реакции приложения. 

° Тестирование по диаграмме или таблице состояний (рассмотрено ранее }). 

e Тестирование по спецификациям (ѕресіћсайоп-Баѕеа testing, black box testing) (рас- 
смотрено ранее! 3}). 

° Тестирование по моделям поведения приложения (model-based ќеѕііпо256) — техника 
тестирования, в которой исследование приложения (и разработка тест-кейсов) стро- 
ится на некой модели: таблице принятия решений 01, таблице или диаграмме состоя- 
ний}, пользовательских сценариев 48}, модели нагрузки{3} и т.д. 

° Тестирование на основе вариантов использования (use case testing???) — техника 
тестирования (по методу чёрного ящика), в которой тест-кейсы разрабатываются на 
основе вариантов использования. Варианты использования выступают в основном 
источником информации для шагов тест-кейса, в то время как наборы входных данных 
удобно разрабатывать с помощью техник выбора входных данных 6}. В общем случае 
источником информации для разработки тест-кейсов в этой технике могут выступать 
не только варианты использования, но и другие пользовательские требования} в лю- 
бом их виде. В случае если методология разработки проекта подразумевает использо- 
вание пользовательских историй, этот вид тестирования может быть заменён тестиро- 
ванием на основе пользовательских историй (user story testing?>8). 

° Параллельное тестирование (parallel {е$#п5259) — техника тестирования, в которой 
поведение нового (или модифицированного) приложения сравнивается с поведением 
эталонного приложения (предположительно работающего верно). Термин «параллель- 
ное тестирование» также может использоваться для обозначения способа проведения 
тестирования, когда несколько тестировщиков или систем автоматизации выполняют 
работу одновременно, т. е. параллельно. Очень редко (и не совсем верно) под парал- 
лельным тестированием понимают мутационное тестирование 6}. 

° Тестирование на основе случайных данных (random ќеѕііпо260) — техника тестиро- 
вания (по методу чёрного ящика), в которой входные данные, действия или даже сами 


255 Decision Table Testing. А black box test design technique in which test cases are designed to execute the combinations 
of inputs and/or stimuli (causes) shown in a decision table (a table showing combinations of inputs and/or stimuli (causes) with 
their associated outputs and/or actions (effects), which can be used to design test cases). [ISTQB Glossary] 

256 Model-based Testing. Testing based on a model of the component or system under test, e.g., reliability growth models, 
usage models such as operational profiles or behavioral models such as decision table or state transition diagram. [ISTQB 
Glossary] 

257 Use case testing. A black box test design technique in which test cases are designed to execute scenarios of use cases. 
[ISTQB Glossary] 

258 User story testing. A black box test design technique in which test cases are designed based on user stories to verify their 
correct implementation. [ISTQB Glossary] 

259 Parallel testing. Testing a new or an altered data processing system with the same source data that is used in another 
system. The other system is considered as the standard of comparison. [ISPE Glossary] 

260 Random testing. A black box test design technique where test cases are selected, possibly using a pseudo-random 
generation algorithm, to match an operational profile. This technique can be used for testing non-functional attributes such as 
reliability and performance. [ISTQB Glossary] 
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тест-кейсы выбираются на основе (псевдо)случайных значений так, чтобы соответ- 
ствовать операционному профилю (operational profile?61) — подмножеству действий, 
соответствующих некоей ситуации или сценарию работы с приложением. Не стоит пу- 
тать этот вид тестирования с т.н. «обезьяньим тестированием» (monkey їезїїпр?®?). 

° А/В-тестирование (А/В testing, split іеѕіїіпо263) — техника тестирования, в которой ис- 
следуется влияние на результат выполнения операции изменения одного из входных 
параметров. Однако куда чаще можно встретить трактовку А/В-тестирования как тех- 
нику тестирования удобства использования}, в которой пользователям случайным 
образом предлагаются разные варианты элементов интерфейса, после чего оценивает- 
ся разница в реакции пользователей. 


ZA Крайне подробное описание некоторых видов тестирования, относящихся к данной 
О классификации, можно найти в книге Ли Коупленда «Практическое руководство по 
разработке тестов» (Lee Copeland, «А Ргасіііопегѕ Guide to Software Test Design»): 


• Тестирование по таблице принятия решений — в главе 5. 
e Тестирование по диаграмме или таблице состояний — в главе 7. 
» Тестирование на основе вариантов использования — в главе 9. 


261 Operational profile. The representation of а distinct set of tasks performed Бу the component ог system, possibly based 
on user behavior when interacting with the component or system, and their probabilities of occurrence. A task is logical rather 
that physical and can be executed over several machines or be executed in non-contiguous time segments. [ISTQB Glossary] 

262 Monkey testing. Testing by means of a random selection from a large range of inputs and by randomly pushing buttons, 
ignorant of how the product is being used. [ISTQB Glossary] 

263 Split testing is a design for establishing a causal relationship between changes and their influence on user-observable 
behavior. [«Controlled experiments on the web: survey and practical guide», Коп Kohav] 
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2.3.2.14. КЛАССИФИКАЦИЯ ПО МОМЕНТУ ВЫПОЛНЕНИЯ (ХРОНОЛОГИИ) 


Несмотря на многочисленные попытки создать единую хронологию тестирования, предпри- 
нятые многими авторами, по-прежнему можно смело утверждать, что общепринятого решения, 
которое в равной степени подходило бы для любой методологии управления проектами, любого 
отдельного проекта и любой его стадии, просто не существует. 

Если попытаться описать хронологию тестирования одной общей фразой, то можно сказать, 
что происходит постепенное наращивание сложности самих тест-кейсов и сложности логики их 
выбора. 


e Общая универсальная логика последовательности тестирования состоит в том, чтобы Ha- 
чинать исследование каждой задачи с простых позитивных тест-кейсов, к которым посте- 
пенно добавлять негативные (но тоже достаточно простые). Лишь после того, как наиболее 
типичные ситуации покрыты простыми тест-кейсами, следует переходить к более сложным 
(опять же, начиная с позитивных). Такой подход — не догма, но к нему стоит прислушаться, 
т. к. углубление на начальных этапах в негативные (к тому же — сложные) тест-кейсы может 
привести к ситуации, в которой приложение отлично справляется с кучей неприятностей, 
но не работает на элементарных повседневных задачах. Ещё раз суть универсальной после- 
довательности: 


1) простое позитивное тестирование; 
2) простое негативное тестирование; 

3) сложное позитивное тестирование; 
4) сложное негативное тестирование. 


• Последовательность тестирования, построенная по иерархии компонентов: 

° Восходящее тестирование (bottom-up ќеѕііпо264) — инкрементальный подход к инте- 
грационному тестированию? 7}, в котором в первую очередь тестируются низкоуровне- 
вые компоненты, после чего процесс переходит на всё более и более высокоуровневые 
компоненты. 

° Нисходящее тестирование (top-down testing?65) — инкрементальный подход K инте- 
грационному тестированию}, в котором в первую очередь тестируются высокоуров- 
невые компоненты, после чего процесс переходит на всё более и более низкоуровневые 
компоненты. 

° Тибридное тестирование (hybrid ѓеѕііїпо266) — комбинация восходящего и нисходяще- 
го тестирования, позволяющая упростить и ускорить получение результатов оценки 
приложения. 

=“ Поскольку термин «гибридное» является синонимом «комбинированное», под «гиб- 
@ ридным тестированием» может пониматься практически любое сочетание двух и более 
видов, техник или подходов к тестированию. Всегда уточняйте, о гибриде чего именно 

идёт речь. 


264 Bottom-up testing. An incremental approach to integration testing where the lowest level components are tested first, 
and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the 
hierarchy is tested. [ISTQB Glossary] 

265 Top-down testing. An incremental approach to integration testing where the component at the top of the component 
hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower 
level components. The process is repeated until the lowest level components have been tested. [ISTQB Glossary] 

266 Hybrid testing, Sandwich testing. First, the inputs for functions are integrated in the bottom-up pattern discussed 
above. The outputs for each function are then integrated in the top-down manner. The primary advantage of this approach is the 
degree of support for early release of limited functionality. [«Integration testing techniques», Kratika Parmar] 
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° Последовательность тестирования, построенная по концентрации внимания на требовани- 
ях и их составляющих: 


1) Тестирование требований, которое может варьироваться от беглой оценки в стиле 
«всё ли нам понятно» до весьма формальных подходов, в любом случае первично по 
отношению к тестированию того, как эти требования реализованы. 

2) Тестирование реализации функциональных составляющих требований логично прово- 
дить до тестирования реализации нефункциональных составляющих, т. к. если что-то 
просто не работает, то проверять производительность, безопасность, удобство и про- 
чие нефункциональные составляющие бессмысленно, а чаще всего и вовсе невозможно. 

3) Тестирование реализации нефункциональных составляющих требований часто ста- 
новится логическим завершением проверки того, как реализовано то или иное требо- 
вание. 


• Типичные общие сценарии используются в том случае, когда не существует явных пред- 
посылок к реализации иной стратегии. Такие сценарии могут видоизменяться и комбини- 
роваться (например, весь «типичный общий сценарий 1» можно повторять на всех шагах 
«типичного общего сценария 2»). 

° Типичный общий сценарий 1: 


1) Дымовое тестирование}. 
2) Тестирование критического пути{81. 
3) Расширенное тестирование!82}. 


° Типичный общий сценарий 2: 
1) Модульное тестирование 7}. 


2) Интеграционное тестирование!" ”}. 
3) Системное тестирование! 8}. 


° Типичный общий сценарий 3: 
1) Альфа-тестирование!86}. 
2) Бета-тестирование!86}. 
3) Гамма-тестирование!86}. 


В завершение ещё раз подчеркнём, что рассмотренные здесь классификации тестирования 
не являются чем-то каноническим и незыблемым. Они лишь призваны упорядочить огромный 
объём информации о различных видах деятельности тестировщиков и упростить запоминание 
соответствующих фактов. 
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2.3.3. АЛЬТЕРНАТИВНЫЕ И ДОПОЛНИТЕЛЬНЫЕ 
КЛАССИФИКАЦИИ ТЕСТИРОВАНИЯ imam 


Для полноты картины остаётся лишь показать альтернативные взгляды на классификацию 
тестирования. Одна из них (рисунки 2.3.1 и 2.3.}) представляет не более чем иную комбинацию 
ранее рассмотренных видов и техник. Вторая (рисунки 2.3.К и 2.3.1) содержит много новых опре- 
делений, но их подробное изучение выходит за рамки данной книги, и потому будут даны лишь 
краткие пояснения (при необходимости вы можете ознакомиться с первоисточниками, которые 
указаны для каждого определения в сноске). 


техникам тестирования в первоисточниках посвящены десятки и сотни страниц. По- 
жалуйста, не ожидайте от этого раздела подробных пояснений, их не будет, т. к. это — 
«очень дополнительный» материал. 


Ещё раз подчеркнём: здесь приведены лишь определения. Соответствующим видам и 
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Рисунок 2.3.1 — Классификация тестирования согласно книге «Foundations of Software Testing: 
ISTQB Certification» (Erik Van Veenendaal, Isabel Evans) (русскоязычный вариант) 
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Рисунок 2.3. — Классификация тестирования согласно книге «Foundations of Software Testing: 
ISTQB Certification» (Erik Van Veenendaal, Isabel Evans) (англоязычный вариант) 


В следующей классификации встречаются как уже рассмотренные пункты, так и ранее He pac- 
смотренные (отмечены пунктирной линией). Краткие определения не рассмотренных ранее ви- 
дов тестирования представлены после рисунков 2.3.К и 2.3.1. 
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Рисунок 2.3.К — Классификация тестирования согласно 1$ОЛЕСЛЕЕЕ 29119-4 


(русскоязычный вариант) 
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Рисунок 2.3.1 — Классификация тестирования согласно 1$ОЛЕСЛЕЕЕ 29119-4 


(англоязычный вариант) 


ШЕШІ 2.3. ВИДЫ И НАПРАВЛЕНИЯ ТЕСТИРОВАНИЯ 109 


• Тестирование на основе дерева классификаций (classification ігее267 method268) — техника 
тестирования (по методу чёрного ящика), в которой тест-кейсы создаются на основе иерар- 
хически организованных наборов эквивалентных входных и выходных данных. 


• Тестирование на основе синтаксиса (syntax {езп5269) — техника тестирования (по методу 
чёрного ящика), в которой тест-кейсы создаются на основе определения наборов входных и 
выходных данных. 


e Комбинаторные техники или комбинаторное тестирование (combinatorial {е$Нп$270) — 
способ выбрать подходящий набор комбинаций тестовых данных для достижения уста- 
новленного уровня тестового покрытия в случае, когда проверка всех возможных наборов 
значений тестовых данных невозможна за имеющееся время. Существуют следующие ком- 
бинаторные техники: 


° Тестирование всех комбинаций (all combinations ќеѕііпр271) — тестирование всех B03- 
можных комбинаций всех значений всех тестовых данных (например, всех параметров 
функции). 

° Попарное тестирование (рассмотрено ранее”). 

° Тестирование с выбором значений-представителей (each choice {е$Нп5272) — тестиро- 
вание, при котором по одному значению из каждого набора тестовых данных должно 
быть использовано хотя бы в одном тест-кейсе. 

° Тестирование с выбором базового набора значений (base choice testing???) — тести- 
рование, при котором выделяется набор значений (базовый набор), который исполь- 
зуется для проведения тестирования в первую очередь, а далее тест-кейсы строятся на 
основе выбора всех базовых значений, кроме одного, которое заменяется значением, 
не входящим в базовый набор. 


Также см. классификацию тестирования на основе выбора входных данных 6}, которая 
расширяет и дополняет данный список. 


e Тестирование по графу причинно-следственных связей (cause-effect graphing?”4) — тех- 
ника тестирования (по методу чёрного ящика), в которой тест-кейсы разрабатываются на 
основе графа причинно-следственных связей (графического представления входных дан- 
ных и воздействий со связанными с ними выходными данными и эффектами). 


267 Classification tree. А tree showing equivalence partitions hierarchically ordered, which is used to design test cases in 
the classification tree method. [ISTQB Glossary] 

268 Classification tree method. A black box test design technique in which test cases, described by means of a classification 
tree, are designed to execute combinations of representatives of input and/or output domains. [ISTQB Glossary] 

269 Syntax testing. A black box test design technique in which test cases are designed based upon the definition of the input 
domain and/or output domain. [ISTQB Glossary] 

270 Combinatorial testing. A means to identify a suitable subset of test combinations to achieve a predetermined level of 
coverage when testing an object with multiple parameters and where those parameters themselves each have several values, 
which gives rise to more combinations than are feasible to test in the time allowed. [ISTQB Glossary] 

271 All combinations testing. Testing of all possible combinations of all values for all parameters. [«Guide to advanced 
software testing, 2nd edition», Anne Matte Hass]. 

272 Each choice testing. One value from each block for each partition must be used in at least one test case. [«Introduction 
to Software Testing. Chapter 4. Input Space Partition Testing», Paul Ammann & Jeff Offutt] 

273 Base choice testing. A base choice block is chosen for each partition, and a base test is formed by using the base choice 
for each partition. Subsequent tests are chosen by holding all but one base choice constant and using each non-base choice 
in each other parameter. [«Introduction to Software Testing. Chapter 4. Input Space Partition Testing», Paul Ammann & Jeff 
Offutt] 

274 Cause-effect graphing. A black box test design technique in which test cases are designed from cause-effect graphs 
(a graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects), which can be used to design 
test cases). [ISTQB Glossary] 
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e Тестирование по потоку данных (data-flow ќеѕіїпо275) — семейство техник тестирования, 
основанных на выборе отдельных путей из потока управления с целью исследования собы- 
тий, связанных с изменением состояния переменных. Эти техники позволяют обнаружить 
такие ситуации, как: переменная определена, но нигде не используется; переменная исполь- 
зуется, но не определена; переменная определена несколько раз до того, как она использует- 
ся; переменная удалена до последнего случая использования. 


Здесь придётся немного погрузиться в теорию. Над переменной в общем случае может вы- 
полняться несколько действий (покажем на примере переменной х): 

• объявление (declaration): int х; 

• определение (definition, d-use): x = 99; 

» использование в вычислениях (computation use, c-use): z = X + 1; 

• использование в условиях (predicate use, р-изе): if (x > 17) {... }; 

• удаление (kill, k-use): х = null; 


Теперь можно рассмотреть техники тестирования на основе потока данных. Они крайне 
подробно описаны в разделе 3.3 главы 5 книги Бориса Бейзера «Техники тестирования ПО» 
(«Software Testing Techniques, Second Edition», Boris Вешег), мы же приведём очень краткие 
пояснения: 

° Проверка использования всех объявлений (all-definitions testing?”6) — тестовым Ha- 
бором проверяется, что для каждой переменной существует путь от её определения к 
её использованию в вычислениях или условиях. 

° Проверка всех вычислений на основе всех объявлений (all-c-uses їезїїпө?77) — тесто- 
вым набором проверяется, что для каждой переменной существует путь от каждого её 
определения к её использованию в вычислениях. 

° Проверка всех ветвлений на основе всех объявлений (all-p-uses testing?78) — тесто- 
вым набором проверяется, что для каждой переменной существует путь от каждого её 
определения к её использованию в условиях. 

° Проверка всех вычислений и ветвлений на основе всех объявлений (all-uses 
{е$Н15279) — тестовым набором проверяется, что для каждой переменной существует 
хотя бы один путь от каждого её определения к каждому её использованию в вычисле- 
ниях и в условиях. 

° Проверка использования всех объявлений и всех путей без переобъявлений (без 
циклов или с однократными повторениями циклов) (all-du-paths {е$Н 115280) — тесто- 
вым набором для каждой переменной проверяются все пути от каждого её определения 
к каждому её использованию в вычислениях и в условиях (самая мощная стратегия, 
которая в то же время требует наибольшего количества тест-кейсов). 


275 Data flow testing. А white box test design technique in which test cases are designed to execute definition-use pairs of 
variables. [ISTQB Glossary] 

276 All-definitions strategy. Test set requires that every definition of every variable is covered by at least one use of that 
variable (c-use or p-use). [«Software Testing Techniques, Second Edition», Boris Beizer] 

277 All-computation-uses strategy. For every variable and every definition of that variable, include at least one definition- 
free path from the definition to every computation use. [«Software Testing Techniques, Second Edition», Boris Beizer] 

278 All-predicate-uses strategy. For every variable and every definition of that variable, include at least one definition-free 
path from the definition to every predicate use. [«Software Testing Techniques, Second Edition», Boris Beizer] 

279 All-uses strategy. Test set includes at least one path segment from every definition to every use that can be reached by 
that definition. [«Software Testing Techniques, Second Edition», Boris Beizer] 

280 All-DU-path strategy. Test set includes every du path from every definition of every variable to every use of that 
definition. [«Software Testing Techniques, Second Edition», Boris Beizer] 
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Для лучшего понимания и запоминания приведём оригинальную схему из книги Бори- 
са Бейзера (там она фигурирует под именем «Figure 5.7. Relative Strength of Structural Test 
Strategies»), показывающую взаимосвязь стратегий тестирования на основе потока данных 
(рисунок 2.3.11). 


All-Paths 
All-DU-Paths 
All-Uses 


All-C-Uses/Some-P-Uses All-P-Uses/Some-C-Uses 


All-C-Uses All-Defs 


All-P-Uses 


Branch 


Statement 


Рисунок 2.3.т — Взаимосвязь и относительная мощность стратегий тестирования 
на основе потока данных (по книге Бориса Бейзера «Техники тестирования ПО») 
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2.3.4. КЛАССИФИКАЦИЯ ПО ПРИНАДЛЕЖНОСТИ 


К ТЕСТИРОВАНИЮ ПО МЕТОДУ БЕЛОГО 


И ЧЁРНОГО ЯЩИКОВ namm 


Типичнейшим вопросом на собеседовании для начинающих тестировщиков является прось- 
ба перечислить техники тестирования по методу белого и чёрного ящиков. Ниже представлена 
таблица 2.3.4, в которой все вышерассмотренные виды тестирования соотнесены с соответст- 
вующим методом. Эту таблицу можно использовать также как справочник по видам тестирова- 


ния (они представлены в той же последовательности, в какой описаны в данной главе). 


Важно! В источниках наподобие [5ТОВ-глоссария многие виды и техники тестирова- 
ния жёстко соотнесены с методами белого или чёрного ящика. Но это не значит, что их 
невозможно применить в другом, не отмеченном методе. Так, например, тестирование 


на основе классов эквивалентности отнесено к методу чёрного ящика, но оно прекрас- 
но подходит и для написания модульных тест-кейсов, являющихся ярчайшими пред- 
ставителями тестирования по методу белого ящика. 


Воспринимайте данные из предстваленной ниже таблицы не как «этот вид тестирова- 
ния может применяться только для...», а как «чаще всего этот вид тестирования при- 


меняется для...» 


Таблица 2.3.4 — Виды и техники тестирования 
в контексте методов белого и чёрного ящиков 


Вид тестирования 


Вид тестирования 


Белый | Чёрный 


приложений{84} 


(русскоязычное название) (англоязычное название) ящик | ящик 
Статическое тестирование!" 2} Static testing Да Нет 
Динамическое тестирование!" 2} Dynamic testing Изредка Да 
Ручное тестирование!" 5} Manual testing Мало Да 
Автоматизированное тестирование 5} | Automated testing Да Да 
Модульное (компонентное) Unit testing, Module testing, 
тестирование! 7} Component testing 8 е 
Интеграционное тестирование\77} Integration testing Да Да 
Системное тестирование! 8} System testing Мало Да 
Дымовое тестирование(80) а Мало Да 
Тестирование критического пути} Critical path test Mano Да 
Расширенное тестирование! 2} Extended test Мало Да 
Позитивное тестирование!83) Positive testing Да Да 
Негативное тестирование! 3} Negative testing, Invalid testing Да Да 
Тестирование веб-приложений{84} Web-applications testing Да Да 
и ыы Mobile applications testing Да Да 
оа а Desktop applications testing Да Да 
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Таблица 2.3.4 [продолжение] 
Вид тестирования Вид тестирования Белый | Чёрный 
(русскоязычное название) (англоязычное название) ящик | ящик 
Тестирование уровня представления(85) |РгезепаНоп tier testing Мало Да 
Тестирование уровня бизнес-логики!85) |Business logic tier testing Да Да 
Тестирование уровня данных} Data tier testing Да Мало 
Альфа-тестирование{86} Alpha testing Mano Да 
Р Почти 
Бета-тестирование{86} Beta testing Да 
никогда 
{86} : Почти 
Гамма-тестирование Gamma testing Да 
никогда 
Scripted testing 
Тестирование на основе тест-кейсові87) Ж а а 
á Test case based testing Д Д 
Исследовательское тестирование{87} Exploratory testing Нет Да 
Свободное (интуитивное 
бе! =i ) Ad hoc testing Her Да 
тестирование 
Функциональное тестирование} Functional testing Да Да 
Нефункциональное тестирование{88} Non-functional testing Да Да 
Инсталляционное тестирование(88) Installation testing Изредка| Да 
Регрессионное тестирование} Regression testing Да Да 
Повторное тестирование! 9} Re-testing, Confirmation testing Да Да 
р : Крайне 
Приёмочное тестирование} Acceptance testing к Да 
: : Крайне 
Операционное тестирование} Operational testing те Да 
Тестирование удобства z: ; Крайне 
{90} Usability testing Да 
использования редко 
На: | Крайне 
Тестирование доступности} Accessibility testing оаа Да 
Тестирование интерфейса} Interface testing Да Да 
Тестирование безопасности 1} Security testing Да Да 
Тестирование интернационализации 1} |Internationalization testing Мало Да 
Тестирование локализации l} Localization testing Мало Да 
Тестирование совместимости Ц Compatibility testing Mano Да 
Конфигурационное тестирование 1} Configuration testing Mano Да 
Кросс-браузерное тестирование 2} Cross-browser testing Мало Да 
Data quality testin 
Тестирование данных и баз данных!92) qua ity tesung | Да Мало 
and Database integrity testing 
Тестирование использования ТГ А Крайне 
P {92} Resource utilization testing P Да 
ресурсов редко 
Сравнительное тестирование 3} Comparison testing Her Да 
Демонстрационное тестирование 3} Qualification testing Her Да 
| Крайне 
Избыточное тестирование 3} Exhaustive testing P Her 


редко 
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Таблица 2.3.4 [продолжение] 


Вид тестирования Вид тестирования Белый | Чёрный 
(русскоязычное название) (англоязычное название) ящик | ящик 

р Е : Крайне 

Тестирование надёжности 3} Reliability testing p Да 
7, : Крайне 

Тестирование восстанавливаемостиі93} |Весоуега Шу testing лы Да 
К ; ү Крайне 

Тестирование отказоустойчивости{?3} | Failover testing г Да 
А Крайне 

Тестирование производительности3} | Регќоггтпапсе testing ае Да 
А | : Крайне 

Нагрузочное тестирование 4} Load testing, Capacity testing „ө 


Тестирование масштабируемости!) Scalability testing 


Объёмное тестирование? Volume testing 


Стрессовое тестирование 4} Stress testing 


Конкурентное тестирование 4} Concurrency testing 


Инвазивное тестирование} Intrusive testing 


Неинвазивное тестирование $} Nonintrusive testing 


Тестиров ание под управлением 


данными 98} Data-driven testing 


Тестиров ание под управлением 


ен © Keyword-driven testing 


Тестирование предугадыванием 


ошибок 6} Error guessing 


Эвристическая оценка!96) Heuristic evaluation 


Мутационное тестирование 6} Mutation testing 


Тестирование добавлением onmbokt?ó} |Error seeding 


Тестирование на основе классов 
эквивалентности{6} 


Equivalence partitioning 


Тестирование на основе граничных 


условий Boundary value analysis 


Доменное тестирование!97} Domain testing, Domain analysis 


Попарное тестирование 7} Pairwise testing 


Тестирование на основе 


Orthogonal array testin 
ортогональных массивов 7} 5 у 8 


Тестирование в процессе разработки} | Development testing 
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Таблица 2.3.4 [продолжение] 
Вид тестирования Вид тестирования Белый Чёрный 
(русскоязычное название) (англоязычное название) ящик | ящик 
Тестирование по потоку управления 8} |Control flow testing Да Нет 
Тестирование по потоку данных} Data flow testing Да Нет 
Тестирование по диаграмме DE : 
| ла. (98) State transition testing Да Нет 
или таблице состояний 
Инспекция (аудит) кода} Code review, code inspection Да Нет 
Тестирование на основе выражений{9} |Ѕ(аќетепі testing Да Нет 
Тестирование на основе ветвей 3} Branch testing Да Нет 
Тестирование на основе условий} Condition testing Да Нет 
Тестирование на основе комбинаций 2 . 
Ро {99} Ё Multiple condition testing Да Нет 
условий 
Тестирование на основе отдельных А те а 
Ро А 199} Modified condition decision 
условий, порождающих ветвление Да Нет 
Е coverage testing 
(«решающих условий») 
Тестирование на основе решений} Decision testing Да Нет 
Тестирование на основе путей 100} Path testing Да Нет 
Тестирование по таблице И 
р P т Decision table testing Да Да 
принятия решений 
Тестирование по моделям поведения 
р {101} А А Model-based testing Да Да 
приложения 
Тестирование на основе вариантов | 
Р {101} P Use case testing Да Да 
использования 
Параллельное тестирование 101} Parallel testing Да Да 
Тестирование на основе | 
r 1101} Random testing Да Да 
случайных данных 
А/В-тестирование 02} А/В testing, Split testing Her Да 
Восходящее тестирование! 103} Bottom-up testing Да Да 
Нисходящее тестирование(103) Top-down testing Да Да 
Гибридное тестирование 03} Hybrid testing Да Да 
Тестирование на основе А 
Р 21109} Classification tree method Да Да 
дерева классификаций 
Тестирование на основе синтаксиса{109} |Syntax testing Да Да 
Комбинаторные техники 109} | 
Р Combinatorial testing Да Да 
(комбинаторное тестирование) 
Тестирование всех комбинаций 09} АП combinations testing Да Нет 
T a : : 
естирование свыбором Each choice testing Да Нет 


значений-представителей 09} 


116 Раздел 2: ОСНОВНЫЕ ЗНАНИЯ И УМЕНИЯ ШШШ 


Таблица 2.3.4 [окончание] 


Вид тестирования 
(русскоязычное название) 


Вид тестирования 
(англоязычное название) 


Белый | Чёрный 
ящик | ящик 


Тестирование с выбором базового 


на основе всех объявлений 110} 


Проверка использования 

всех объявлений и всех путей 
без переобъявлений 1} 

(без циклов или с однократными 
повторениями циклов) 


All-du-paths testing 


E Base choice testin а Нет 
набора значений 09} Ы Д 
Тестирование по гра } 
P papy 21109} Cause-effect graphing Мало Да 

причинно-следственных связеи 
Проверка использования =: . 

Ровер < 110} All-definitions testing Да Нет 
всех объявлений 
П оверка всех вычислений на основе . 

ровер {110} All-c-uses testing Да Нет 
всех объявлений 
Проверка всех ветвлений на основе всех . 

ровер » {110} All-p-uses testing Да Нет 
объявлений 
П оверка всех вычислений и ветвлений A 

ровер All-uses testing Да Нет 


Да Нет 
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ЧЕК-ЛИСТЫ, ТЕСТ-КЕЙСЫ, 
НАБОРЫ ТЕСТ-КЕЙСОВ 


2.4.1. ЧЕК-ЛИСТ mumm 


Как легко можно понять из предыдущих глав, тестировщику приходится работать с огромным 
количеством информации, выбирать из множества вариантов решения задач и изобретать но- 
вые. В процессе этой деятельности объективно невозможно удержать в голове все мысли, а по- 
тому продумывание и разработку тест-кейсов рекомендуется выполнять с использованием так 
называемых «чек-листов». 


скобки282, т. к. в общем случае чек-лист — это просто набор идей: идей по тестирова- 


© Чек-лист (checklist?8!) — набор идей [тест-кейсов]. Последнее слово не зря взято в 
нию, идей по разработке, идей по планированию и управлению — любых идей. 


Чек-лист чаще всего представляет собой обычный и привычный нам список, который мо- 
жет быть: 


e Списком, в котором последовательность пунктов не имеет значения (например, список зна- 
чений некоего поля). 

e Списком, в котором последовательность пунктов важна (например, шаги в краткой ин- 
струкции). 

e Структурированным (многоуровневым) списком (вне зависимости от учёта последователь- 
ности пунктов), что позволяет отразить иерархию идей. 


Важно понять, что нет и не может быть никаких запретов и ограничений при разработке 
чек-листов — главное, чтобы они помогали в работе. Иногда чек-листы могут даже выражаться 
графически (например, с использованием ментальных карт?83 или концепт-карт284), хотя тради- 
ционно их составляют в виде многоуровневых списков. 

Поскольку в разных проектах встречаются однотипные задачи, хорошо продуманные и акку- 
ратно оформленные чек-листы могут использоваться повторно, чем достигается экономия сил и 
времени. 


Для того чтобы чек-лист был действительно полезным инструментом, он должен обладать ря- 
дом важных свойств. 


281 Понятие «чек-листа» не завязано на тестирование как таковое — это совершенно универсальная техника, 
которая может применяться в любой без исключения области жизни. В русском языке вне контекста информаци- 
онных технологий чаще используется понятное и привычное слово «список» (например, «список покупок», «список 
дел» ит.д.), но в тестировании прижилась калькированная с английского версия — «чек-лист». 

282 Если у вас возник вопрос «почему тут использованы квадратные скобки», ознакомьтесь с синтаксисом «рас- 
ширенной формы Бэкуса-Наура», который де-факто является стандартом описания выражений в ИТ. См. «Extended 
Backus-Naur form», Wikipedia. [https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form] 

283 «Mind map», Wikipedia. [http://en.wikipedia.org/wiki/Mind_map] 

284 «Concept map», Wikipedia. [http://en.wikipedia.org/wiki/Concept_map] 
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Логичность. Чек-лист пишется не «просто так», а на основе целей и для того, чтобы помочь 
в достижении этих целей. К сожалению, одной из самых частых и опасных ошибок при состав- 
лении чек-листа является превращение его в свалку мыслей, которые никак не связаны друг с 


другом. 


Последовательность и структурированность. Со структурированностью всё достаточно 
просто — она достигается за счёт оформления чек-листа в виде многоуровневого списка. Что до 
последовательности, то даже в том случае, когда пункты чек-листа не описывают цепочку дей- 
ствий, человеку всё равно удобнее воспринимать информацию в виде неких небольших групп 
идей, переход между которыми является понятным и очевидным (например, сначала можно про- 
писать идеи простых позитивных тест-кейсові83), потом идеи простых негативных тест-кейсов, 
потом постепенно повышать сложность тест-кейсов, но не стоит писать эти идеи вперемешку). 


Полнота и неизбыточность. Чек-лист должен представлять собой аккуратную «сухую вы- 
жимку» идей, в которых нет дублирования (часто появляется из-за разных формулировок одной 
и той же идеи), и в то же время ничто важное не упущено. 


Правильно создавать и оформлять чек-листы также помогает восприятие их не только как 
хранилища наборов идей, но и как «требования для составления тест-кейсов». Эта мысль при- 
водит к пересмотру и переосмыслению свойств качественных требований (см. главу «Свойства 
качественных требований» {44} в применении к чек-листам. 


Задание 2.4.а: перечитайте главу «Свойства качественных требований» 4} и подумай- 
те, какие свойства качественных требований можно также считать и свойствами каче- 
ственных чек-листов. 


Итак, рассмотрим процесс создания чек-листа. В главе «Пример анализа и тестирования тре- 
бований» 3} приведён пример итоговой версии требований, который мы и будем исполь- 
зовать. 

Поскольку мы не можем сразу «протестировать всё приложение» (это слишком большая за- 
дача, чтобы решить её одним махом), нам уже сейчас нужно выбрать некую логику построения 
чек-листов — да, их будет несколько (в итоге их можно будет структурированно объединить в 
один, но это не обязательно). 

Типичными вариантами такой логики является создание отдельных чек-листов для: 


e различных уровней функционального тестирования{80}; 

• отдельных частей (модулей и подмодулей!127)) приложения; 

• отдельных требований, групп требований, уровней и типов требований}; 
• типичных пользовательских сценариев 48}, 

• частей или функций приложения, наиболее подверженных рискам. 


Этот список можно расширять и дополнять, можно комбинировать его пункты, получая, на- 
пример, чек-листы для проверки наиболее типичных сценариев, затрагивающих некую часть 
приложения. 

Чтобы проиллюстрировать принципы построения чек-листов, мы воспользуемся логикой 
разбиения функций приложения по степени их важности на три категории (см. классификацию 
по убыванию степени важности функций приложения{80}): 

e Базовые функции, без которых существование приложения теряет смысл (т. е. самые важ- 
ные — то, ради чего приложение вообще создавалось), или нарушение работы которых 
создаёт объективные серьёзные проблемы для среды исполнения. (См. «Дымовое тестиро- 
вание» (80!). 
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e Функции, востребованные большинством пользователей в их повседневной работе. 
(См. «Тестирование критического пути» 81). 

• Остальные функции (разнообразные «мелочи», проблемы с которыми не сильно повлия- 
ют на ценность приложения для конечного пользователя). (См. «Расширенное тестиро- 
вание» {82}. 


ФУНКЦИИ, БЕЗ КОТОРЫХ СУЩЕСТВОВАНИЕ ПРИЛОЖЕНИЯ ТЕРЯЕТ СМЫСЛ 
Сначала приведём целиком весь чек-лист для дымового тестирования, а потом разберём его 
подробнее. 


• Конфигурирование и запуск. 
e Обработка файлов: 


Форматы входных файлов 
TXT HTML MD 
к WIN1251 + + + 
ORFES CP866 + + + 
входных файлов 
KOI8R + + + 


e Остановка. 
Да, и всё. Здесь перечислены все ключевые функции приложения. 


Конфигурирование и запуск. Если приложение невозможно настроить для работы в поль- 
зовательской среде, оно бесполезно. Если приложение не запускается, оно бесполезно. Если на 
стадии запуска возникают проблемы, они могут негативно отразиться на функционировании 
приложения и потому также заслуживают пристального внимания. 

Примечание: в нашем примере мы столкнулись со скорее нетипичным случаем — приложение 
конфигурируется параметрами командной строки, а потому разделить операции «конфигуриро- 
вания» и «запуска» не представляется возможным; в реальной жизни для подавляющего боль- 
шинства приложений эти операции выполняются раздельно. 


Обработка файлов. Ради этого приложение и разрабатывалось, потому здесь даже на стадии 
создания чек-листа мы не поленились создать матрицу, отражающую все возможные комбина- 
ции допустимых форматов и допустимых кодировок входных файлов, чтобы ничего не забыть и 
подчеркнуть важность соответствующих проверок. 


Остановка. С точки зрения пользователя эта функция может не казаться столь уж важной, 
но остановка (и запуск) любого приложения связаны с большим количеством системных опера- 
ций, проблемы с которыми могут привести к множеству серьёзных последствий (вплоть до не- 
возможности повторного запуска приложения или нарушения работы операционной системы). 


ФУНКЦИИ, ВОСТРЕБОВАННЫЕ БОЛЬШИНСТВОМ ПОЛЬЗОВАТЕЛЕЙ 


Следующим шагом мы будем выполнять проверку того, как приложение ведёт себя в обыч- 
ной повседневной жизни, пока не затрагивая экзотические ситуации. Очень частым вопросом 
является допустимость дублирования проверок на разных уровнях функционального тестиро- 
вания!80} — можно ли так делать. Одновременно и «нет», и «да». «Нет» в том смысле, что не до- 
пускается (не имеет смысла) повторение тех же проверок, которые только что были выполнены. 
«Да» в том смысле, что любую проверку можно детализировать и снабдить дополнительными 
деталями. 
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e Конфигурирование и запуск: 
° С верными параметрами: 


= Значения SOURCE_DIR, DESTINATION_DIR, ГОС_ЕШЕ_МАМЕ указаны и содер- 
жат пробелы и кириллические символы (повторить для форматов путей в Windows 
и *nix файловых системах, обратить внимание на имена логических дисков и раз- 


делители имён каталогов (“/” и “\”)). 
= Значение LOG_FILE_NAME не указано. 


° Без параметров. 
° С недостаточным количеством параметров. 
° С неверными параметрами: 
a Недопустимый путь SOURCE_DIR. 
= Недопустимый путь DESTINATION_DIR. 
= Недопустимое имя [ОС ЕПЕ МАМЕ. 
= РрЕЅТІМАТІОМ РІК находится внутри Ѕ5ООКСЕ РІК. 
= Значения ОЕЅТІЧАТІОМ ПІК и SOURCE_DIR совпадают. 


• Обработка файлов: 


° Разные форматы, кодировки и размеры: 


Форматы входных файлов 
TXT HTML MD 
WIN1251 100 KB 50 МБ 10 MB 
CP866 10 MB 100 KB 50 MB 
Кодировки KOI8R 50 MB 10 MB 100 KB 
входных Любая 0 байт 
файлов Любая 50 МБ+1Б 50 МБ+1Б 50 МБ+1Б 
- Любой недопустимый формат 
Любая Повреждения в допустимом формате 


° Недоступные входные файлы: 
" Нет прав доступа. 
" Файл открыт и заблокирован. 
" Файл сатрибутом «только для чтения». 
e Остановка: 
° Закрытием окна консоли. 
e Журнал работы приложения: 
° Автоматическое создание (при отсутствии журнала). 
° Продолжение (дополнение журнала) при повторных запусках. 
e Производительность: 


° Элементарный тест с грубой оценкой. 


Обратите внимание, что чек-лист может содержать не только «предельно сжатые тезисы», 
но и вполне развёрнутые комментарии, если это необходимо — лучше пояснить суть идеи 
подробнее, чем потом гадать, что же имелось в виду. 

Также обратите внимание, что многие пункты чек-листа носят весьма высокоуровневый ха- 
рактер, и это нормально. Например, «повреждения в допустимом формате» (см. матрицу с коди- 
ровками, форматами и размерами) звучит расплывчато, но этот недочёт будет устранён уже на 
уровне полноценных тест-кейсов. 
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ОСТАЛЬНЫЕ ФУНКЦИИ И ОСОБЫЕ СЦЕНАРИИ 


Пришло время обратить внимание на разнообразные мелочи и хитрые нюансы, проблемы с 
которыми едва ли сильно озаботят пользователя, но формально всё же будут считать ошибками. 


• Конфигурирование и запуск: 
° Значения SOURCE_DIR, DESTINATION_DIR, LOG_FILE_NAME: 


" В разных стилях (М/іпаоугѕ-пути + *пїх-пути) — одно в одном стиле, другое — 
в другом. 
a С использованием ОМС-имён. 
a LOG_FILE_NAME внутри SOURCE_DIR. 
a LOG_FILE_NAME внутри DESTINATION_DIR. 
° Размер ГОС_ЕШЕ_МАМЕ на момент запуска: 
= 2-4 ГБ. 
= 4+ ГБ. 
° Запуск двух и более копий приложения с: 
= Одинаковыми параметрами ЅООКСЕ РІК, РЕЅТІМАТІОМ РІК, ГОС_ЕШЕ_ 


МАМЕ. 

= Одинаковыми ЅООКСЕ_ РІК и 0С ЕПЕ МАМЕ, но разными РЕЅТІМАТІОМ _ 
DIR. 

= Одинаковыми DESTINATION_DIR и LOG_FILE_NAME, но разными SOURCE_ 
DIR. 


e Обработка файлов: 


° Файл верного формата, в котором текст представлен в двух и более поддерживаемых 
кодировках одновременно. 
° Размер входного файла: 


a 2-4 ГБ. 
a 4+ ГБ. 


стах — это совершенно нормально и справедливо: нет и не может быть некоего «един - 
ственно верного идеального чек-листа», и ваши идеи вполне имеют право на существо- 
вание, потому составьте свой собственный чек-лист или отметьте недостатки, которые 
вы заметили в приведённом выше чек-листе. 


Ө Задание 2.4.Ъ: возможно, вам захотелось что-то изменить в приведённых выше чек-ли- 


Как мы увидим в следующей главе, создание качественного тест-кейса может потребовать дли- 
тельной кропотливой и достаточно монотонной работы, которая при этом не требует от опыт- 
ного тестировщика сильных интеллектуальных усилий, а потому переключение между работой 
над чек-листами (творческая составляющая) и расписыванием их в тест-кейсы (механическая 
составляющая) позволяет разнообразить рабочий процесс и снизить утомляемость. Хотя, ко- 
нечно, написание сложных и притом качественных тест-кейсов может оказаться ничуть не менее 
творческой работой, чем продумывание чек-листов. 
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2.4.2. ТЕСТ-КЕЙС р 
И ЕГО ЖИЗНЕННЫЙ ЦИКЛ таваа 


ТЕРМИНОЛОГИЯ И ОБЩИЕ СВЕДЕНИЯ 


Для начала определимся с терминологией, поскольку здесь есть много путаницы, вызванной 
разными переводами англоязычных терминов на русский язык и разными традициями в тех или 
иных странах, фирмах и отдельных командах. 

Во главе всего лежит термин «тест». Официальное определение звучит так. 


Q Тест (їеѕ1285) — набор из одного или нескольких тест-кейсов. 


Поскольку среди всех прочих терминов этот легче и быстрее всего произносить, в зависимости 
от контекста под ним могут понимать и отдельный пункт чек-листа, и отдельный шаг в тест-кей- 
се, и сам тест-кейс, и набор тест-кейсов и... продолжать можно долго. Главное здесь одно: если 
вы слышите или видите слово «тест», воспринимайте его в контексте. 


Теперь рассмотрим самый главный для нас термин — «тест-кейс». 


Тест-кейс (test саѕе286) — набор входных данных, условий выполнения и ожидаемых 
результатов, разработанный с целью проверки того или иного свойства или поведения 


программного средства. 


Под тест-кейсом также может пониматься соответствующий документ, представляю- 
щий формальную запись тест-кейса. 


Мы ещё вернёмся к этой мысли{153}, но уже сейчас критически важно понять и запомнить: 
если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, 
и/или не ясна цель тест-кейса — это плохой тест-кейс (иногда он не имеет смысла, иногда его и 
вовсе невозможно выполнить). 

Примечание: иногда термин «test case» на русский язык переводят как «тестовый случай». Это 
вполне адекватный перевод, но из-за того, что «тест-кейс» короче произносить, наибольшее рас- 
пространение получил именно этот вариант. 


Остальные термины, связанные с тестами, тест-кейсами и тестовыми сценариями, на 
данном этапе можно прочитать просто в ознакомительных целях. Если вы откроете 


[5ТОВ-глоссарий на букву «Т», вы увидите огромное количество терминов, тесно CBA- 
занных друг с другом перекрёстными ссылками: на начальном этапе изучения тести- 
рования нет необходимости глубоко рассматривать их все, однако некоторые всё же 
заслуживают внимания. Они представлены ниже. 


285 Test. А set of опе ог more test cases. [ISTQB Glossary] 

286 Test case. A set of input values, execution preconditions, expected results and execution postconditions, developed for 
a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific 
requirement. [ISTQB Glossary] 
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Высокоуровневый тест-кейс (high level test саѕе287) — тест-кейс без конкретных входных дан- 
ных и ожидаемых результатов. 

Как правило, ограничивается общими идеями и операциями, схож по своей сути с подроб- 
но описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестирова- 
нии!77) и системном тестировании!(78), а также на уровне дымового тестирования{0}. Может ory- 
жить отправной точкой для проведения исследовательского тестирования{87} или для создания 
низкоуровневых тест-кейсов. 


Низкоуровневый тест-кейс (low level test саѕе288) — тест-кейс с конкретными входными дан- 
ными и ожидаемыми результатами. 

Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наи- 
более классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать 
именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой 
информацией можно пренебречь, при этом не снизив ценность тест-кейса. 


Спецификация тест-кейса (test case зрессаНоп?89) — документ, описывающий набор 
тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые резуль- 
таты) для тестируемого элемента (test item??0, test оБјесі291). 


Спецификация теста (test specification???) — документ, состоящий из спецификации тест-ди- 
зайна (test design specification?’3), спецификации тест-кейса (test case ѕресіћсаііоп289) и/или спец- 
ификации тест-процедуры (test procedure specification??4). 


Тест-сценарий (test зсепаг10295, test procedure specification, test script) — документ, описываю- 
щий последовательность действий по выполнению теста (также известен как «тест-скрипт»). 


(3) Внимание! Из-за особенностей перевода очень часто под термином «тест-сценарий» 
(«тестовый сценарий») имеют в виду набор тест-кейсов{ 148}, 


ЦЕЛЬ НАПИСАНИЯ ТЕСТ-КЕЙСОВ 


Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность 
такого подхода варьируется в очень широком диапазоне в зависимости от множества факторов). 
Наличие же тест-кейсов позволяет: 


e Структурировать и систематизировать подход к тестированию (без чего крупный проект 
почти гарантированно обречён на провал). 


287 High level test case (logical test case). А test case without concrete (implementation level) values for input data and 
expected results. Logical operators are used; instances of the actual values are not yet defined and/or available. [ISTQB Glossary] 


288 Low level test case. A test case with concrete (implementation level) values for input data and expected results. Logical 
operators from high level test cases are replaced by actual values that correspond to the objectives of the logical operators. 
[ISTQB Glossary] 

289 Test case specification. A document specifying a set of test cases (objective, inputs, test actions, expected results, and 
execution preconditions) for a test item. [ISTQB Glossary] 

290 Test item. The individual element to be tested. There usually is one test object and many test items. [ISTQB Glossary] 

291 Test object. The component or system to be tested. [ISTQB Glossary] 

292 Test specification. A document that consists of a test design specification, test case specification and/or test procedure 
specification. [ISTQB Glossary] 

293 Test design specification. A document specifying the test conditions (coverage items) for a test item, the detailed test 
approach and identifying the associated high level test cases. [ISTQB Glossary] 

294 Test procedure specification (test procedure). A document specifying a sequence of actions for the execution of a test. 
Also known as test script or manual test script. [ISTQB Glossary] 

295 Test scenario. A document specifying a sequence of actions for the execution of a test. Also known as test script or 
manual test script. [ISTQB Glossary] 
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Вычислять метрики тестового покрытия (test соуегаре296 metrics) и принимать меры по его 
увеличению (тест-кейсы здесь являются главным источником информации, без которого 
существование подобных метрик теряет смысл). 

Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится 
тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе 
количества и т.д.). 

Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками 
(тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это 
отражено в требованиях). 

Хранить информацию для длительного использования и обмена опытом между сотрудника- 
ми и командами (или как минимум — не пытаться удержать в голове сотни страниц текста). 
Проводить регрессионное тестирование! и повторное тестирование! (которые без 
тест-кейсов было бы вообще невозможно выполнить). 

Повышать качество требований (мы это уже рассматривали: написание чек-листов и 
тест-кейсов — хорошая техника тестирования требований{?}). 

Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту. 


ЖИЗНЕННЫЙ ЦИКЛ ТЕСТ-КЕЙСА 


В 


отличие от отчёта о дефекте, у которого есть полноценный развитый жизненный цикл 71}, 


для тест-кейса речь скорее идёт о наборе состояний (см. рисунок 2.4.а), в которых он может Ha- 
ходиться (жирным шрифтом отмечены наиболее важные состояния). 


Создан (new) — типичное начальное состояние практически любого артефакта. Тест-кейс 
автоматически переходит в это состояние после создания. 

Запланирован (planned, ready for testing) — в этом состоянии тест-кейс находится, когда он 
или явно включён в план ближайшей итерации тестирования, или как минимум готов для 
выполнения. 

Не выполнен (not tested) — в некоторых системах управления тест-кейсами это состояние 
заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии 
означает, что он готов к выполнению, но ещё не был выполнен. 

Выполняется (work in progress) — если тест-кейс требует длительного времени на выполне- 
ние, он может быть переведён в это состояние для подчёркивания того факта, что работа 
идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало 
времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из 
трёх следующих состояний — «провален», «пройден успешно» или «заблокирован». 
Пропущен (skipped) — бывают ситуации, когда выполнение тест-кейса отменяется по сооб- 
ражениям нехватки времени или изменения логики тестирования. 

Провален (failed) — данное состояние означает, что в процессе выполнения тест-кейса был 
обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одно- 
му шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения 
тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их 
ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естествен- 
но, по обнаруженному дефекту создаётся отчёт о дефекте). 

Пройден успешно (passed) — данное состояние означает, что в процессе выполнения 
тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и факти- 
ческих результатов его шагов. 


296 Coverage (test coverage). The degree, expressed as а percentage, to which а specified coverage item (ап entity ог 
property used as a basis for test coverage, e.g. equivalence partitions or code statements) has been exercised by a test suite. 
[ISTQB Glossary] 
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Создан еж | 


Запланирован Не выполнен o <> : 


A 
У 
Требует доработки 


Провален пройден 


i yemem Заблокирован | «с > 


Закрыт 


Рисунок 2.4.а — Жизненный цикл (набор состояний) тест-кейса 


» Заблокирован (blocked) — данное состояние означает, что по какой-то причине выполне- 
ние тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не по- 
зволяющего реализовать некий пользовательский сценарий). 

• Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях 
«провален / пройден успешно / заблокирован / пропущен». В данное состояние в некоторых 
системах управления тест-кейс переводят, чтобы подчеркнуть тот факт, что на данной ите- 
рации тестирования все действия с ним завершены. 

• Требует доработки (not ready) — как видно из схемы, в это состояние (и из него) тест-кейс 
может быть преведён в любой момент времени, если в нём будет обнаружена ошибка, если 
изменятся требования, по которым он был написан, или наступит иная ситуация, не позво- 
ляющая считать тест-кейс пригодным для выполнения и перевода в иные состояния. 


Ещё раз подчеркнём, что в отличие от жизненного цикла дефекта, который достаточно стан- 
дартизирован и формализован, для тест-кейса описанное выше носит общий рекомендательный 
характер, рассматривается скорее как разрозненный набор состояний (а не строгий жизнен- 
ный цикл) и может сильно отличаться в разных компаниях (в связи с имеющимися традициями 
и/или возможностями систем управления тест-кейсами). 
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2.4.3. АТРИБУТЫ (ПОЛЯ) ТЕСТ-КЕЙСА mamm 


Как уже было сказано выше, термин «тест-кейс» может относиться к формальной записи 
тест-кейса в виде технического документа. Эта запись имеет общепринятую структуру, компо- 
ненты которой называются атрибутами (полями) тест-кейса. 

В зависимости от инструмента управления тест-кейсами внешний вид их записи может не- 
много отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся 
неизменной. 

Общий вид всей структуры тест-кейса представлен на рисунке 2.4.Ъ. 


Связанное с тест-кейсом требование 


Ожидаемый результат по 
каждому шагу тест-кейса 


Приоритет 


Иденти- 
фикатор Заглавие (суть) тест-кейса 


Га- Загрузка | Галерея, загрузка 1. Появляется окно за- 
файла файла, имя со спец- грузки картинки. 
символами 2. Появляется диалого- 
Приготовления: создать | вое окно браузера вы- 
непустой файл с именем | бора файла для 3a- 
#$%^&.]рд. грузки. 

Модуль и подмо- 1. Нажать кнопку «Загру- | 3. Имя выбранного 
дуль приложения зить картинку». файла появляется в 

2 Нажать кнопку «Вы- поле «Файл». 
Исходные данные, не- орать». 4. Диалоговое ОКНО 
обходимые для выпол- 3. Выбрать из списка файла закрывается, в 
нения тест-кейса приготовленный файл. поле «Файл» появля- 
4. Нажать кнопку «ОК». ется полное имя 

5. Нажать кнопку «Доба- | файла. 

вить в галерею». 5. Выбранный файл 
появляется в списке 
файлов галереи. 


Шаги тест-кейса 


Рисунок 2.4.6 — Общий вид тест-кейса 


Теперь рассмотрим каждый атрибут подробно. 


Идентификатор (identifier) представляет собой уникальное значение, позволяющее однознач- 
но отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем слу- 
чае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если 
позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: 
включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро опреде- 
лить цель тест-кейса и часть приложения (или требований), к которой он относится (например: 
UR216_S12_DB_Neg). 


Приоритет (priority) показывает важность тест-кейса. Он может быть выражен буквами (А, В, 
C, D, Е), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», 
«крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, 


но чаще всего лежит в диапазоне от трёх до пяти. 
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Приоритет тест-кейса может коррелировать с: 


• важностью требования, пользовательского сценария 48} или функции, с которыми связан 

тест-кейс; 

• потенциальной важностью дефекта1\180}, на поиск которого направлен тест-кейс; 

e степенью риска, связанного с проверяемым тест-кейсом требованием, сценарием или функ- 

цией. 

Основная задача этого атрибута — упрощение распределения внимания и усилий команды 
(более высокоприоритетные тест-кейсы получают их больше), а также упрощение планирования 
и принятия решения о том, чем можно пожертвовать в некоей форс-мажорной ситуации, не по- 
зволяющей выполнить все запланированные тест-кейсы. 


Связанное с тест-кейсом требование (requirement) показывает то основное требование, про- 
верке выполнения которого посвящён тест-кейс (основное — потому, что один тест-кейс может 
затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса, 
как прослеживаемость 45}. 

Частые вопросы, связанные с заполнением этого поля, таковы: 


e Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться вне прямой при- 
вязки к требованиям, и (пока?) значение этого поля определить сложно. Хоть такой вариант 
и не считается хорошим, он достаточно распространён. 

e Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются вы- 
брать одно самое главное или «более высокоуровневое» (например, вместо того, чтобы пере- 
числять К56.1, В56.2, К56.3 и т.д., можно просто написать R56). Чаще всего в инструментах 
управления тестами это поле представляет собой выпадающий список, где можно выбрать 
только одно значение, и этот вопрос становится неактуальным. К тому же многие тест-кей- 
сы всё же направлены на проверку строго одного требования, и для них этот вопрос также 
неактуален. 


Модуль и подмодуль приложения (module and submodule) указывают на части приложения, 
к которым относится тест-кейс, и позволяют лучше понять его цель. 

Идея деления приложения на модули и подмодули проистекает из того, что в сложных систе- 
мах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протести- 
ровать это приложение» становится недопустимо сложным. Тогда приложение логически разде- 
ляется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). 
И вот уже для таких небольших частей приложения придумать чек-листы и создать хорошие 
тест-кейсы становится намного проще. 

Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной 
команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные 
подходы к такому разделению или даже просто разные названия одних и тех же частей прило- 
жения. 

Теперь — самое сложное: как выбираются модули и подмодули. В реальности проще всего 
отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложе- 
нии} можно выделить такую иерархию модулей и подмодулей: 


e Механизм запуска: 


° механизм анализа параметров; 
° механизм сборки приложения; 
° механизм обработки ошибочных ситуаций. 
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e Механизм взаимодействия с файловой системой: 


° механизм обхода дерева SOURCE_DIR; 
° механизм обработки ошибочных ситуаций. 


e Механизм преобразования файлов: 

° механизм определения кодировок; 

° механизм преобразования кодировок; 

° механизм обработки ошибочных ситуаций. 
e Механизм ведения журнала: 


° механизм записи журнала; 
° механизм отображения журнала в консоли; 
° механизм обработки ошибочных ситуаций. 


Согласитесь, что Такие длинные названия с постоянно повторяющимся словом «механизм» 
читать и запоминать сложно. Перепишем: 


» Стартер: 
° анализатор параметров; 
° сборщик приложения; 
° обработчик ошибок. 

• Сканер: 


° обходчик; 
° обработчик ошибок. 


e Преобразователь: 
° детектор; 
° конвертер; 
° обработчик ошибок. 
e Регистратор: 
° дисковый регистратор; 


° консольный регистратор; 
° обработчик ошибок. 


Но что делать, если мы не знаем «внутренностей» приложения (или не очень разбираемся в 
программировании)? Модули и подмодули можно выделять на основе графического интерфей- 
са пользователя (крупные области и элементы внутри них), на основе решаемых приложением 
задач и подзадач и т.д. Главное, чтобы эта логика была одинаковым образом применена ко всему 
приложению. 


2 Внимание! Частая ошибка! Модуль и подмодуль приложения — это НЕ действия, это 
@ именно структурные части, «куски» приложения. В заблуждение вас могут ввести та- 
кие названия, как, например, «печать, настройка принтера» (но здесь имеются в виду 

именно части приложения, отвечающие за печать и за настройку принтера (и названы 


они отглагольными существительными), ане процесс печати или настройки принтера). 


Сравните (на примере человека): «дыхательная система, лёгкие» — это модуль и под- 
модуль, а «дыхание», «сопение», «чихание» — нет; «голова, мозг» — это модуль и под- 


модуль, а «кивание», «думание» — нет. 
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Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест-кейса, как прослежи- 
ваемость! 145}. 


Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной идеи 
(цели) тест-кейса без обращения кего остальным атрибутам. Именно это поле является наиболее 
информативным при просмотре списка тест-кейсов. 


Сравните. 
Плохо Хорошо 
Тест 1 Запуск, одна копия, верные параметры 
Тест 2 Запуск одной копии с неверными путями 
Тест 78 (улучшенный) Запуск, много копий, без конфликтов 
Остановка Остановка по Ctrl+C 
Закрытие Остановка закрытием консоли 


Заглавие тест-кейса может быть полноценным предложением, фразой, набором словосочета- 


ний — главное, чтобы выполнялись следующие условия: 


• Информативность. 


• Хотя бы относительная уникальность (чтобы не путать разные тест-кейсы). 


“ы Внимание! Частая ошибка! Если инструмент управления тест-кейсами не требует mn- 
сать заглавие, его всё равно надо писать. Тест-кейсы без заглавий превращаются в 
мешанину информации, использование которой сопряжено с колоссальными и совер- 


шенно бессмысленными затратами. 


И ещё одна небольшая мысль, которая может помочь лучше формулировать заглавия. В до- 
словном переводе с английского «test сазе» обозначает «тестовый случай (ситуация)». Так вот, 
заглавие как раз и описывает этот случай (ситуацию), т.е. что происходит в тест-кейсе, какую 
ситуацию он проверяет. 


Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation, initial 
data, setup), позволяют описать всё то, что должно быть подготовлено до начала выполнения 
тест-кейса, например: 

• Состояние базы данных. 

» Состояние файловой системы и её объектов. 

„ Состояние серверов и сетевой инфраструктуры. 


То, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и 
таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении. 
Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представь- 
те, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты 
таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин, 
если не хватило денег и т.д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефек- 
те конфет вида «конфеты невкусные потому, что закрыт магазин». 
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2% Некоторые авторы не следуют этой логике и допускают в приготовлениях работу с TEC- 
@ тируемым приложением. И здесь нет «правильного варианта» — просто в одной тра- 
диции решено одним образом, в другой — другим. Во многом это — ещё и термино- 
логическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять 
без участия тестируемого приложения, в то время как «precondition» по смыслу ближе 
к описанию состояния тестируемого приложения. В реальной рабочей обстановке вам 
достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами, 

чтобы понять, какой точки зрения на данный вопрос они придерживаются. 


Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо pea- 
лизовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов таковы: 


• начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск 
приложения, очевидные операции с интерфейсом и т.п.); 

„ даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в буду- 
щем случайно «приклеить» описание этого шага к новому тексту); 

e если вы пишете на русском языке, используйте безличную форму (например, «открыть», 
«ввести», «добавить» вместо «откройте», «введите», «добавьте»), ванглийском языке не надо 
использовать частицу «tO» (т.е. «запустить приложение» будет «start application», не «to start 
application»); 

» соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, 
уровнемі80) ит. д. — в зависимости от этих и многих других факторов степень детализации 
может варьироваться от общих идей до предельно чётко прописанных значений и указаний; 

• ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, 
«повторить шаги 3-5 со значением... »); 


e пишите шаги последовательно, без условных конструкций вида «если... то...». 


GA Внимание! Частая ошибка! Категорически запрещено ссылаться на шаги из других 
@ тест-кейсов и другие тест-кейсы целиком: если те, другие тест-кейсы будут изменены 
или удалены, ваш тест-кейс начнёт ссылаться на неверные данные или в пустоту, а если 

в процессе выполнения те, другие тест-кейсы или шаги приведут к возникновению 


ошибки, вы не сможете закончить выполнение вашего тест-кейса. 


Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают реакцию 
приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номе- 
ру результата. 

По написанию ожидаемых результатов можно порекомендовать следующее: 


• описывайте поведение системы так, чтобы исключить субъективное толкование (например, 
«приложение работает верно» — плохо, «появляется окно с надписью...» — хорошо); 

• пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие 
сомнения в том, что результат некоего шага будет совершенно тривиальным и очевидным 
(если вы всё же пропускаете ожидаемый результат для какого-то тривиального действия, 
лучше оставить в списке ожидаемых результатов пустую строку — это облегчает вос- 
приятие); 

• пишите кратко, но не в ущерб информативности; 

• избегайте условных конструкций вида «если... то...». 
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2233 Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описывается KOP- 

@ РЕКТНАЯ работа приложения. Нет и не может быть ожидаемого результата в виде 
«приложение вызывает ошибку в операционной системе и аварийно завершается с по- 
терей всех пользовательских данных». 


При этом корректная работа приложения вполне может предполагать отображение со- 
общений о неверных действиях пользователя или неких критических ситуациях. Так, 
сообщение «Невозможно сохранить файл по указанному пути: на целевом носителе 
недостаточно свободного места» — это не ошибка приложения, это его совершенно 
нормальная и правильная работа. Ошибкой приложения (в этой же ситуации) было бы 
отсутствие такого сообщения, и/или повреждение, или потеря записываемых данных. 


Для более глубокого понимания принципов оформления тест-кейсов рекомендуется прямо 
сейчас ознакомиться с главой «Типичные ошибки при разработке чек-листов, тест-кейсов и на- 
боров тест-кейсов» 61. 
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2.4.4. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА 
УПРАВЛЕНИЯ ТЕСТИРОВАНИЕМ ишш 


Инструментальных средств управления тестированием (test management 10097) очень 
много298, к тому же многие компании разрабатывают свои внутренние средства решения этой 
задачи. 

Не имеет смысла заучивать, как работать с тест-кейсами в том или ином инструментальном 
средстве — принцип везде един, и соответствующие навыки нарабатываются буквально за пару 
дней. Что на текущий момент важно понимать, так это общий набор функций, реализуемых та- 
кими инструментальными средствами (конечно, то или иное средство может не реализовывать 
какую-то функцию из этого списка и/или реализовывать не вошедшие в список функции): 


» создание тест-кейсов и наборов тест-кейсов; 

e контроль версий документов с возможностью определить, кто внёс те или иные изменения, 
и отменить эти изменения, если требуется; 

• формирование и отслеживание реализации плана тестирования, сбор и визуализация раз- 
нообразных метрик, генерирование отчётов; 

• интеграция с системами управления дефектами, фиксация взаимосвязи между выполнени- 
ем тест-кейсов и созданными отчётами о дефектах; 

• интеграция с системами управления проектами; 

e интеграция с инструментами автоматизированного тестирования, управление выполнени- 
ем автоматизированных тест-кейсов. 


Иными словами, хорошее инструментальное средство управления тестированием берёт на 
себя все рутинные технические операции, которые объективно необходимо выполнять в процес- 
се реализации жизненного цикла тестирования}. Огромным преимуществом также является 
способность таких инструментальных средств отслеживать взаимосвязи между различными до- 
кументами и иными артефактами, взаимосвязи между артефактами и процессами и т.д., подчи- 
няя эту логику системе разграничения прав доступа и гарантируя сохранность и корректность 
информации. 


Для общего развития и лучшего закрепления темы об оформлении тест-кейсов126} мы сейчас 
рассмотрим несколько картинок с формами из разных инструментальных средств. 

Здесь вполне сознательно не приведено никакого сравнения или подробного описания — по- 
добных обзоров достаточно в Интернете, и они стремительно устаревают по мере выхода новых 
версий обозреваемых продуктов. 

Но интерес представляют отдельные особенности интерфейса, на которые мы обратим вни- 
мание в каждом из примеров (важно: если вас интересует подробное описание каждого поля, 
связанных с ним процессов и т.д., обратитесь к официальной документации — здесь будут лишь 
самые краткие пояснения). 


297 Test management tool. А tool that provides support to the test management and control part of a test process. И often 
has several capabilities, such as testware management, scheduling of tests, the logging of results, progress tracking, incident 
management and test reporting. [ISTQB Glossary] 

298 «Test management tools» [http://www.opensourcetesting.org/testmgt.php] 
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ОАСотріІеѓе299 
1а: (Auto Generate оча М 
Title: Status: у 
Priority: м Assigned То: м. 
Avg Вип Time: (Auto Calculated) Last Run Status: (Auto Calculated) 
Last Run Test Set: (Auto Calculated) Last Run Configuration: 
Last Run Release: 
Description: [та |v v Ак А” Yy |= = @ b = = 5 
Омтег м Version: 
Execution Type: м Теѕї Туре: м 
Latest Notes: Add New Note 
Default Host Name: у 
Linked Items: “ы Link to Items... 
File Attachments: ани 
Browse... 
Browse... 
Browse... 
Browse... 
| Сапсе! | | Submit | [Submit/Add another | 


Рисунок 2.4.с — Создание тест-кейса в QAComplete 


[4 (идентификатор), как видно из соответствующей надписи, автогенерируемый. 

Title (заглавие), как и в большинстве систем, является обязательным для заполнения. 

Priority (приоритет) по умолчанию предлагает значения high (высокий), medium (средний), 
low (низкий). 

Folder name (расположение) является аналогом полей «Модуль» и «Подмодуль» и позволя- 
ет выбрать из выпадающего древовидного списка соответствующее значение, описывающее, 
к чему относится тест-кейс. 

Status (статус) показывает текущее состояние тест-кейса: new (новый), approved (утверждён), 
awaiting approval (на рассмотрении), in design (в разработке), outdated (устарел), rejected (от- 
клонён). 

Assigned to (исполнитель) указывает, кто в данный момент является «основной рабочей cn- 
лой» по данному тест-кейсу (или кто должен принять решение о, например, утверждении 
тест-кейса). 

Last Run Status (результат последнего запуска) показывает, прошёл ли тест успешно (passed) 
или завершился неудачей (failed). 

Last Run Configuration (конфигурация, использованная для последнего запуска) показывает, 
на какой аппаратно-программной платформе тест-кейс выполнялся в последний раз. 


299 ОАСотрее [http://smartbear.com/product/test-management-tool/qacomplete/] 
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9. Avg Вип Time (среднее время выполнения) содержит вычисленное автоматически среднее 
время, необходимое на выполнение тест-кейса. 

10. Last Вип Test Set (в последний раз выполнялся в наборе) содержит информацию о наборе 
тест-кейсов, в рамках которого тест-кейс выполнялся последний раз. 

11. Last Run Release (последний раз выполнялся на выпуске) содержит информацию о выпуске 
(билде) программного средства, на котором тест-кейс выполнялся последний раз. 

12. Description (описание) позволяет добавить любую полезную информацию о тест-кейсе (вклю- 
чая особенности выполнения, приготовления и т.д.). 

13. Owner (владелец) указывает на владельца тест-кейса (как правило — его автора). 

14. Execution Туре (способ выполнения) по умолчанию предлагает только значение manual (руч- 
ное выполнение), но при соответствующих настройках и интеграции с другими продуктами 
список можно расширить (как минимум добавить automated (автоматизированное выпол- 
нение)). 

15. Version (версия) содержит номер текущей версии тест-кейса (фактически — счётчик того, 
сколько раз тест-кейс редактировали). Вся история изменений сохраняется, предоставляя 
возможность вернуться к любой из предыдущих версий. 

16. Test Туре (вид теста) по умолчанию предлагает такие варианты, как negative (негативный), 
positive (позитивный), regression (регрессионный), smoke-test (дымный). 

17. Default host name (имя хоста по умолчанию) в основном используется в автоматизированных 
тест-кейсах и предлагает выбрать из списка имя зарегистрированного компьютера, на кото- 
ром установлен специальный клиент. 

18. Linked Items (связанные объекты) представляют собой ссылки на требования, отчёты о де- 
фектах и т.д. 

19. File Attachments (вложения) могут содержать тестовые данные, поясняющие изображения, 
видеоролики ит.д. 


Для описания шагов исполнения и ожидаемых результатов после сохранения общего описа- 
ния тест-кейса становится доступным дополнительный интерфейс: 


Actions | Step# Critical Steps Expected Results 
GK о 81 7 

©к о g 

әк о 33 


Рисунок 2.4.4 — Добавление шагов тест-кейса в QAComplete 


При необходимости можно добавить и настроить свои дополнительные поля, значительно 
расширяющие исходные возможности системы. 
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Рисунок 2.4.е — Создание тест-кейса в TestLink 


1. Title (заглавие) здесь тоже является обязательным для заполнения. 

2. Summary (описание) позволяет добавить любую полезную информацию о тест-кейсе (включая 
особенности выполнения, приготовления и т.д.). 

3. Steps (шаги выполнения) позволяет описать шаги выполнения. 

4. Expected Results (ожидаемые результаты) позволяет описать ожидаемые результаты, относя- 
щиеся к шагам выполнения. 

5. Available Keywords (доступные ключевые слова) содержит список ключевых слов, которые 
можно проассоциировать с тест-кейсом для упрощения классификации и поиска тест-кейсов. 
Это ещё одна вариация идеи «Модулей» и «Подмодулей» (в некоторых системах реализованы 
оба механизма). 

6. Assigned Keywords (назначенные ключевые слова) содержит список ключевых слов, проассоци- 
ированных с тест-кейсом. 


Как видите, инструментальные средства управления тест-кейсами могут быть и достаточно 
минималистичными. 


300 TestLink [http://sourceforge.net/projects/testlink/] 
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TestRail301 
Add Test Case 


Title * 


Section * Type * Priority * Estimate 


[4 
4 
4 


Milestone References 2 


[4 


Preconditions Бө 


econditions of this test case. Reference other test cases with [C#] (e.g. [С17]). 


Steps 
1 Step Description Ө Ө 
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Е 
Expected Result 
Expected Result О 
Step Description +) ə 
Е" a 
B 
Expected Result 
Expected Result 
Add Step 


4” Add Test Case Җ Cancel 
Рисунок 2.4.f — Создание тест-кейса в TestRail 


1. Title (заглавие) здесь тоже является обязательным для заполнения. 


Section (секция) — очередная вариация на тему «Модуль» и «Подмодуль», позволяющая 
создавать иерархию секций, в которых можно размещать тест-кейсы. 

Туре (тип) здесь по умолчанию предлагает выбрать один из вариантов: automated (автома- 
тизированный), functionality (проверка функциональности), performance (производитель- 
ность), regression (регрессионный), usability (удобство использования), other (прочее). 
Priority (приоритет) здесь представлен числами, по которым распределены следующие сло- 
весные описания: MUSt test (обязательно выполнять), test if time (выполнять, если будет вре- 
мя), don't test (не выполнять). 


301 TestRail [http://www.gurock.com/testrail/] 


ШЕШ 2.4. ЧЕК-ЛИСТЫ, ТЕСТ-КЕЙСЫ, НАБОРЫ ТЕСТ-КЕЙСОВ 137 


10. 


Estimate (оценка) содержит оценку времени, которое необходимо затратить на выполнение 
тест-кейса. 

Milestone (ключевая точка) позволяет указать ключевую точку проекта, к которой данный 
тест-кейс должен устойчиво показывать положительный результат (выполняться успешно). 
References (ссылки) позволяет хранить ссылки на такие артефакты, как требования, поль- 
зовательские истории, отчёты о дефектах и иные документы (требует дополнительной на- 
стройки). 

Preconditions (приготовления) представляет собой классику описания предварительных 
условий и необходимых приготовлений к выполнению тест-кейса. 

Step Description (описание шага) позволяет добавлять описание отдельного шага тест-кейса. 
Expected Results (ожидаемые результаты) позволяет описать ожидаемый результат по каждо- 


му шагу. 


Ө Задание 2.4.с: изучите ещё 3-5 инструментальных средств управления тест-кейсами, 


почитайте документацию по ним, посоздавайте в них несколько тест-кейсов. 
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2.4.5. СВОЙСТВА КАЧЕСТВЕННЫХ 


ТЕСТ-КЕЙСОВ mamm 


Даже правильно оформленный тест-кейс может оказаться некачественным, если в нём нару- 


шено одно из следующих свойств. 


Правильный технический язык, точность и единообразие формулировок. Это свойство в 


равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой до- 


кументации. Основные идеи уже были описаны (см. главу «Атрибуты (поля) тест-кейсов» 126}, 


а из самого общего и важного напомним и добавим: 


пишите лаконично, но понятно; 

используйте безличную форму глаголов (например, «открыть» вместо «откройте»); 
обязательно указывайте точные имена и технически верные названия элементов прило- 
жения; 

не объясняйте базовые принципы работы с компьютером (предполагается, что ваши колле- 
ги знают, что такое, например, «пункт меню» и как с ним работать); 

везде называйте одни и те же вещи одинаково (например, нельзя в одном тест-кейсе не- 
кий режим работы приложения назвать «графическое представление», а в другом тот же 
режим — «визуальное отображение», т. к. многие люди могут подумать, что речь идёт о раз- 
ных вещах); 

следуйте принятому на проекте стандарту оформления и написания тест-кейсов (иногда та- 
кие стандарты могут быть весьма жёсткими: вплоть до регламентации того, названия каких 
элементов должны быть приведены в двойных кавычках, а каких — в одинарных). 


Баланс между специфичностью и общностью. Тест-кейс считается тем более специфичным, 


чем более детально в нём расписаны конкретные действия, конкретные значения и т. д., т.е. чем в 


нём больше конкретики. Соответственно, тест-кейс считается тем более общим, чем в нём мень- 


ше конкретики. 


Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (подумайте, какой 


тест-кейс вы бы посчитали хорошим, а какой — плохим и почему): 
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Тест-кейс 1: 


Шаги 


Ожидаемые результаты 


Конвертация из всех поддерживаемых коди- 
ровок 


Приготовления: 


• Создать папки С:/А, С:/В, С:/С, С:/Р. 
e Разместить в папке С:/Ю файлы 1.html, 2.txt, 
3.md из прилагаемого архива. 


1. Запустить приложение, выполнив команду 
«php converter.php с:/а с:/Ъ c:/c/converter.log». 

2. Скопировать файлы l.html, 2.txt, 3.md из 
папки С:/Р в папку С:/А. 

3. Остановить приложение нажатием Crtl+C. 


1. Отображается консольный журнал при- 
ложения с сообщением «текущее_время 
started, source dir с:/а, destination dir с:/, log 
file c:/c/converter.log», в папке С:/С появляет- 
ся файл converter.log, в котором появляется 
запись «текущее время started, source dir с:/а, 
destination dir с:/Ъ, log file c:/c/converter.log». 


2. Файлы 1.html, 2.txt, 3.md появляются в папке 


С:/А, затем пропадают оттуда и появляются 
в папке С:/В. В консольном журнале и фай- 
ле C:/C/converter.log появляются сообщения 
(записи) «текущее время processing 1.html 
(КОІ8-К)», «текущее время processing 2.1хї 
(СР-1251)», «текущее время processing 3.md 
(СР-866)». 


3. В файле С:/С/сопуегѓег Іов появляется запись 


«текущее _ время closed». Приложение завер- 
шает работу. 


Тест-кейс 2: 
Шаги 


Ожидаемые результаты 


Конвертация из всех поддерживаемых коди- 
ровок 


1. Выполнить конвертацию трёх файлов допус- 
тимого размера в трёх разных кодировках 
всех трёх допустимых форматов. 


1. Файлы перемещаются в папку-приёмник, 
кодировка всех файлов меняется на ОТЕ-8. 


Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой — плохим и 
почему», то ответ таков: оба тест-кейса плохие потому, что первый является слишком специфич- 
ным, а второй — слишком общим. Можно сказать, что здесь до абсурда доведены идеи низко- 
уровневых!!23} и высокоуровневых!123) тест-кейсов. 


Почему плоха излишняя специфичность (тест-кейс 1): 


• при повторных выполнениях тест-кейса всегда будут выполняться строго одни и те же дей- 
ствия со строго одними и теми же данными, что снижает вероятность обнаружения ошибки; 

• возрастает время написания, доработки и даже просто прочтения тест-кейса; 

• в случае выполнения тривиальных действий опытные специалисты тратят дополнительные 
мыслительные ресурсы в попытках понять, что же они упустили из виду, т. к. они привыкли, 
что так описываются только самые сложные и неочевидные ситуации. 


Почему плоха излишняя общность (тест-кейс 2): 


e тест-кейс сложен для выполнения начинающими тестировщиками или даже опытными 
специалистами, лишь недавно подключившимися к проекту; 

• недобросовестные сотрудники склонны халатно относиться к таким тест-кейсам; 

• тестировщик, выполняющий тест-кейс, может понять его иначе, чем было задумано авто- 
ром (и в итоге будет выполнен фактически совсем другой тест-кейс). 
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Выход из этой ситуации состоит в том, чтобы придерживаться золотой середины (хотя, ко- 
нечно же, какие-то тесты будут чуть более специфичными, какие-то — чуть более общими). 
Вот пример такого срединного подхода: 


Ожидаемые результаты 


Тест-кейс 3: 
Шаги 
Конвертация из всех поддерживаемых коди- 
ровок 
Приготовления: 


Создать в корне любого диска четыре от- 
дельные папки для входных файлов, выход- 
ных файлов, файла журнала и временного 
хранения тестовых файлов. 

Распаковать содержимое прилагаемого архи- 
ва в папку для временного хранения тесто- 
вых файлов. 


. Запустить приложение, указав в параметрах 


соответствующие пути из приготовления к 
тесту (имя файла журнала — произвольное). 


. Скопировать файлы из папки для временно- 


го хранения в папку для входных файлов. 


3. Остановить приложение. 


1. Приложение запускается и выводит сообще- 


ние о своём запуске в консоль и файл жур- 
нала. 


. Файлы из папки для входных файлов пере- 


мещаются в папку для выходных файлов, 
в консоли и файле журнала отображаются 
сообщения о конвертации каждого из фай- 
лов с указанием его исходной кодировки. 


.Приложение выводит сообщение о завер- 


шении работы в файл журнала и завершает 
работу. 


В этом тест-кейсе есть всё необходимое для понимания и выполнения, но при этом он стал 
короче и проще для выполнения, а отсутствие строго указанных значений приводит к тому, что 


при многократном выполнении тест-кейса (особенно — разными тестировщиками) конкретные 
параметры будут менять свои значения, что увеличивает вероятность обнаружения ошибки. 


Ещё раз главная мысль: сами по себе специфичность или общность тест-кейса не являются 


чем-то плохим, но резкий перекос в ту или иную сторону снижает качество тест-кейса. 


Баланс между простотой и сложностью. Здесь не существует академических определений, 


Преимущества простых тест-кейсов: 


но принято считать, что простой тест-кейс оперирует одним объектом (или в нём явно виден 
главный объект), а также содержит небольшое количество тривиальных действий; сложный 
тест-кейс оперирует несколькими равноправными объектами и содержит много нетривиальных 
действий. 


e ИХ МОЖНО быстро прочесть, легко понять и выполнить; 

• они ПОНЯТНЫ начинающим тестировщикам и новым людям на проекте; 

• они Делают наличие ошибки очевидным (как правило, вних предполагается выполнение по- 
вседневных тривиальных действий, проблемы скоторыми видны невооружённым взглядом 


и не вызывают дискуссий); 


• они упрощают начальную диагностику ошибки, т.к. сужают круг поиска. 


Преимущества сложных тест-кейсов: 


• при взаимодействии многих объектов повышается вероятность возникновения ошибки; 

• пользователи, как правило, используют сложные сценарии, а потому сложные тесты более 
полноценно эмулируют работу пользователей; 

• программисты редко проверяют такие сложные случаи (и они совершенно не обязаны это 


делать). 


Рассмотрим примеры. 
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Слишком простой тест-кейс: 


Шаги 


Ожидаемые результаты 


Запуск приложения 


1. Запустить приложение. 


. Приложение запускается. 


Слишком сложный тест-кейс: 


Шаги 


Ожидаемые результаты 


Повторная конвертация 
Приготовления: 


e Создать в корне любого диска три отдельные 
папки для входных файлов, выходных фай- 
лов, файла журнала. 

• Подготовить набор из нескольких файлов 
максимального поддерживаемого размера 
поддерживаемых форматов с поддержива- 
емыми кодировками, а также нескольких 
файлов допустимого размера, но недопусти- 
мого формата. 


- 


. Запустить приложение, указав в параметрах 
соответствующие пути из приготовления к 
тесту (имя файла журнала — произвольное). 

2. Скопировать в папку для входных файлов 
несколько файлов допустимого формата. 

3. Переместить сконвертированные файлы из 
папки с результирующими файлами в папку 
для входных файлов. 

4. Переместить сконвертированные файлы из 
папки с результирующими файлами в папку 
с набором файлов для теста. 

5. Переместить все файлы из папки с набо- 
ром файлов для теста в папку для входных 
файлов. 

6. Переместить сконвертированные файлы из 

папки с результирующими файлами в папку 

для входных файлов. 


. Файлы постепенно перемещаются из вход- 


ной в выходную папку, в консоли и файле 
журнала появляются сообщения об успеш- 
ной конвертации файлов. 


. Файлы постепенно перемещаются из вход- 


ной в выходную папку, в консоли и файле 
журнала появляются сообщения об успеш- 
ной конвертации файлов. 


. Файлы постепенно перемещаются из вход- 


ной в выходную папку, в консоли и файле 
журнала появляются сообщения об успеш- 
ной конвертации файлов допустимого фор- 
мата и сообщения об игнорировании файлов 
недопустимого формата. 


. Файлы постепенно перемещаются из вход- 


ной в выходную папку, в консоли и файле 
журнала появляются сообщения об успеш- 
ной конвертации файлов допустимого фор- 
мата и сообщения об игнорировании файлов 
недопустимого формата. 


Этот тест-кейс одновременно является слишком сложным по избыточности действий и по 


спецификации лишних данных и операций. 


© 


Задание 2.4.4: перепишите этот тест-кейс, устранив его недостатки, но сохранив об- 
щую цель (проверку повторной конвертации уже ранее сконвертированных файлов). 


Примером хорошего простого тест-кейса может служить тест-кейс 31140} из пункта про спец- 


ифичность и общность. 
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Пример хорошего сложного тест-кейса может выглядеть так: 


Шаги 


Ожидаемые результаты 


Много копий приложения, конфликт файло- 
вых операций 


Приготовления: 


» Создать в корне любого диска три отдельные 
папки для входных файлов, выходных фай- 
лов, файла журнала. 

e Подготовить набор из нескольких файлов 
максимального поддерживаемого размера 
поддерживаемых форматов с поддерживае- 
мыми кодировками. 


1. Запустить первую копию приложения, ука- 
зав в параметрах соответствующие пути из 
приготовления к тесту (имя файла журна- 
ла — произвольное). 

2.Запустить вторую копию приложения с 
теми же параметрами (см. шаг 1). 

3. Запустить третью копию приложения с 
теми же параметрами (см. шаг 1). 

4. Изменить приоритет процессов второй 
(“high”) и третей (“low”) копий. 

5. Скопировать подготовленный набор исход- 
ных файлов в папку для входных файлов. 


3. Все три копии приложения запускаются, в 
файле журнала появляются последовательно 
три записи о запуске приложения. 


5. Файлы постепенно перемещаются из вход- 
ной в выходную папку, в консоли и файле 
журнала появляются сообщения об успеш- 
ной конвертации файлов, а также (возмож- 
но) сообщения вида: 


а. “source file inaccessible, retrying”. 
b. “destination file inaccessible, retrying”. 
с. “log file inaccessible, retrying”. 


Ключевым показателем корректной работы 
является успешная конвертация всех фай- 
лов, а также появление в консоли и файле 
журнала сообщений об успешной конверта- 
ции каждого файла (от одной до трёх запи- 
сей на каждый файл). 


Сообщения (предупреждения) о недоступ- 
ности входного файла, выходного файла или 
файла журнала также являются показателем 
корректной работы приложения, однако их 
количество зависит от многих внешних фак- 
торов и не может быть спрогнозировано за- 
ранее. 


Иногда более сложные тест-кейсы являются также и более специфичными, но это лишь общая 


тенденция, а не закон. Также нельзя по сложности тест-кейса однозначно судить о его приорите- 
те (в нашем примере хорошего сложного тест-кейса он явно будет иметь очень низкий приори- 
тет, т. к. проверяемая им ситуация является искусственной и крайне маловероятной, HO бывают 
и сложные тесты с самым высоким приоритетом). 

Как и в случае специфичности и общности, сами по себе простота или сложность тест-кейсов 
не являются чем-то плохим (более TOTO — рекомендуется начинать разработку и выполнение 
тест-кейсов с простых, а затем переходить ко всё более и более сложным), однако излишняя про- 
стота и излишняя сложность также снижают качество тест-кейса. 


«Показательность» (высокая вероятность обнаружения ошибки). Начиная с уровня тести- 
рования критического пути!80), можно утверждать, что тест-кейс является тем более хорошим, 
чем он более показателен (с большей вероятностью обнаруживает ошибку). Именно поэтому мы 
считаем непригодными слишком простые тест-кейсы — они непоказательны. 


Пример непоказательного (плохого) тест-кейса: 


Шаги 
Запуск и остановка приложения 


Ожидаемые результаты 


1. Приложение запускается. 
2. Приложение завершает работу. 


1. Запустить приложение с корректными пара- 
метрами. 
2. Завершить работу приложения. 
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Пример показательного (хорошего) тест-кейса: 


Шаги 


Запуск с некорректными параметрами, несу- 
ществующие пути 


Ожидаемые результаты 


1.В консоли отображаются нижеуказанные 
сообщения, приложение завершает работу. 


1. Запустить приложение со всеми тремя па-! Сообщения: 
раметрами (SOURCE_DIR, РЕЗТПМАТОМ_ а. SOURCE_DIR: directory not exists ог 
DIR, LOG_FILE_NAME), значения которых inaccessible. 


указывают на несуществующие в файловой 
системе пути (например: 7:\згс\, z:\dst\, z:\log. 
txt при условии, что в системе нет логическо- 
го диска 7). 


b. DESTINATION_DIR: directory not exists 
or inaccessible. 

с. LOG_FILE_NAME: wrong file пате ог 
inaccessible path. 


Обратите внимание, что показательный тест-кейс по-прежнему остался достаточно простым, 
но он проверяет ситуацию, возникновение ошибки в которой несравненно более вероятно, чем 
в ситуации, описываемой плохим непоказательным тест-кейсом. 

Также можно сказать, что показательные тест-кейсы часто выполняют какие-то «интересные 
действия», т. е. такие действия, которые едва ли будут выполнены просто в процессе работы с 
приложением (например: «сохранить файл» — это обычное тривиальное действие, которое явно 
будет выполнено не одну сотню раз даже самими разработчиками, а вот «сохранить файл на 
носитель, защищённый от записи», «сохранить файл на носитель с недостаточным объёмом сво- 
бодного пространства», «сохранить файл в папку, к которой нет доступа» — это уже гораздо 


более интересные и нетривиальные действия). 


Последовательность в достижении цели. Суть этого свойства выражается в том, что все дей- 
ствия в тест-кейсе направлены на следование единой логике и достижение единой цели и не со- 


держат никаких отклонений. 


Примерами правильной реализации этого свойства могут служить представленные в этом 
разделе в избытке примеры хороших тест-кейсов. А нарушение может выглядеть так: 


Шаги 


Ожидаемые результаты 


Конвертация из всех поддерживаемых коди- 
ровок 


Приготовления: 


e Создать в корне любого диска четыре от- 
дельные папки для входных файлов, выход- 
ных файлов, файла журнала и временного 
хранения тестовых файлов. 

e Распаковать содержимое прилагаемого архи- 
ва в папку для временного хранения тесто- 
вых файлов. 


1. Запустить приложение, указав в параметрах 
соответствующие пути из приготовления к 
тесту (имя файла журнала — произвольное). 

2. Скопировать файлы из папки для временно- 
го хранения в папку для входных файлов. 

3. Остановить приложение. 

4. Удалить файл журнала. 

5. Повторно запустить приложение с теми же 
параметрами. 

6. Остановить приложение. 


2. Файлы из папки для входных файлов пере- 


3. Приложение выводит сообщение о завер- 


5. Приложение запускается и выводит сооб- 


6. Приложение выводит сообщение о завер- 


1. Приложение запускается и выводит сообще- 
ние о своём запуске в консоль и файл жур- 
нала. 


мещаются в папку для выходных файлов, 
в консоли и файле журнала отображаются 
сообщения о конвертации каждого из фай- 
лов с указанием его исходной кодировки. 


шении работы в файл журнала и завершает 


работу. 


щение о своём запуске в консоль и заново 
созданный файл журнала. 


шении работы в файл журнала и завершает 


работу. 
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Шаги 3-5 никак не соответствуют цели тест-кейса, состоящей в проверке корректности кон- 
вертации входных данных, представленных во всех поддерживаемых кодировках. 


Отсутствие лишних действий. Чаще всего это свойство подразумевает, что не нужно в шагах 
тест-кейса долго и по пунктам расписывать то, что можно заменить одной фразой: 


Плохо Хорошо 


1. Указать в качестве первого параметра прило- |1. Запустить приложение со всеми тремя KOP- 
жения путь к папке с исходными файлами. ректными параметрами (например, с:\згс\, 
2. Указать в качестве второго параметра прило-| c:\dst\, c:\log.txt при условии, что соответст- 
жения путь к папке с конечными файлами. вующие папки существуют и доступны при- 
3. Указать в качестве третьего параметра при-| ложению). 
ложения путь к файлу журнала. 


4. Запустить приложение. 


Вторая по частоте ошибка — начало каждого тест-кейса с запуска приложения и подробного 
описания по приведению его в то или иное состояние. В наших примерах мы рассматриваем каж- 
дый тест-кейс как существующий в единственном виде в изолированной среде, и потому вынуж- 
дены осознанно допускать эту ошибку (иначе тест-кейс будет неполным), но в реальной жизни 
на запуск приложения будут свои тесты, а длинный путь из многих действий можно описать как 
одно действие, из контекста которого понятно, как это действие выполнить. 


Следующий пример тест-кейса не относится к нашему «Конвертеру файлов», но очень хорошо 
иллюстрирует эту мысль: 


Плохо Хорошо 
1. Запустить приложение. 1. Открыть РОСХ-файл с тремя и более стра- 
2. Выбрать в меню пункт «Файл». ницами. 


3. Выбрать подпункт «Открыть». 

4. Перейти в папку, в которой находится 
хотя бы один файл формата DOCX с тремя и 
более страницами. 


И сюда же можно отнести ошибку с повторением одних и тех же приготовлений во множестве 
тест-кейсов (да, по описанным выше причинам в примерах мы снова вынужденно делаем так, 
как в жизни делать не надо). Куда удобнее объединить тесты в набор1ї148} и указать приготов- 
ления один раз, подчеркнув, нужно или нет их выполнять перед каждым тест-кейсом в наборе. 


матизированном модульном тестировании30? с использованием фреймворков наподо- 
бие JUnit или TestNG — там существует специальный «механизм фиксаций» (fixture), 
автоматически выполняющий указанные действия перед каждым отдельным тестовым 
методом (или их совокупности) или после него. 


© Проблема с подготовительными (и финальными) действиями идеально решена в авто- 


Неизбыточность по отношению к другим тест-кейсам. В процессе создания множества 
тест-кейсов очень легко оказаться в ситуации, когда два и более тест-кейса фактически выпол- 
няют одни и те же проверки, преследуют одни и те же цели, направлены на поиск одних и тех же 
проблем. Способ минимизации количества таких тест-кейсов подробно описан в главе «Виды 
и направления тестирования{66}» (см. такие техники тестирования, как использование классов 
эквивалентности 6} и граничных условий 6}. 


302 Unit testing (component testing). The testing of individual software components. [ISTQB Glossary] 
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Если вы обнаруживаете несколько тест-кейсов, дублирующих задачи друг друга, лучше всего 
или удалить все, кроме одного, самого показательного, или перед удалением остальных на их 
основе доработать этот выбранный самый показательный тест-кейс. 


Демонстративность (способность демонстрировать обнаруженную ошибку очевидным 
образом). Ожидаемые результаты должны быть подобраны и сформулированы таким образом, 
чтобы любое отклонение от них сразу же бросалось в глаза и становилось очевидным, что про- 
изошла ошибка. Сравните выдержки из двух тест-кейсов. 


Выдержка из недемонстративного тест-кейса: 


Шаги Ожидаемые результаты 


5. Разместить в файле текст «Пример длин- |6. Приложение игнорирует файл. 
ного текста, содержащего символы русско- |7. Текст принимает корректный вид в кодиров- 
го и английского алфавита вперемешку.» в) ке ОТЕ-8 с учётом английских букв. 
кодировке КОІ8-К (в слове «Пример» бук- 
вы «р» — английские). 

6. Сохранить файл под именем «test. txt» и OT- 
править файл на конвертацию. 

7. Переименовать файл в «test.txt». 


Выдержка из демонстративного тест-кейса: 


Шаги Ожидаемые результаты 


5. Разместить в файле текст «Ётү={ү!/6. Текст принимает вид: «Пример текста.» 
ЫЕ» (Эти символы представляют| (кодировка UTF8). 
собой словосочетание «Пример текста» в 
кодировке KOI8-R, прочитанной как СР866). 

6. Отправить файл на конвертацию. 


В первом случае тест-кейс плох не только расплывчатостью формулировки «корректный вид 
в кодировке ОТЕ-8 с учётом английских букв», там также очень легко допустить ошибки при 
выполнении: 


• забыть сконвертировать вручную входной текст в КО18-В; 

• не заметить, что в первый раз расширение начинается с пробела; 

e забыть заменить в слове «Пример» буквы «р» на английские; 

• из-за расплывчатости формулировки ожидаемого результата принять ошибочное, но вы- 
глядящее правдоподобно поведение за верное. 


Второй тест-кейс чётко ориентирован на свою цель по проверке конвертации (не содержит 
странной проверки с игнорированием файла с неверным расширением) и описан так, что его 
выполнение не представляет никаких сложностей, а любое отклонение фактического результата 
от ожидаемого будет сразу же заметно. 


Прослеживаемость. Из содержащейся в качественном тест-кейсе информации должно быть 
понятно, какую часть приложения, какие функции и какие требования он проверяет. Частично 
это свойство достигается через заполнение соответствующих полей тест-кейса!126) («Ссылка на 
требование», «Модуль», «Подмодуль»), но и сама логика тест-кейса играет не последнюю роль, 
т. к. в случае серьёзных нарушений этого свойства можно долго с удивлением смотреть, напри- 
мер, на какое требование ссылается тест-кейс, и пытаться понять, как же они друг с другом свя- 
заны. 
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Пример непрослеживаемого тест-кейса: 


Приготовления: файл с не- 
сколькими допустимыми и 
недопустимыми кодиров- 
ками. 

1. Передать файл на конвер- 


тацию. 


Требо- 
р Модуль | Подмодуль Шаги Ожидаемые результаты 
вание 
ПТ-4 Прило- Совмещение кодировок 1. Допустимые кодировки кон- 
жение вертируются верно, недо- 


пустимые остаются без из- 
менений. 


Да, этот тест-кейс плох сам по себе (в качественном тест-кейсе сложно получить ситуацию 
непрослеживаемости), но в нём есть и особые недостатки, затрудняющие прослеживаемость: 


e Ссылка на несуществующее требование (убедитесь сами, требования ПТ-4 Herl’), 
• В поле «Модуль» указано значение «Приложение» (по большому счёту можно было остав- 
лять это поле пустым — это было бы столь же информативно), поле «Подмодуль» не запол- 


нено. 


e По заглавию и шагам можно предположить, что этот тест-кейс ближе всего к ДС-5.1 и 
ДС-5.3, но сформулированный ожидаемый результат не следует явно из этих требований. 


Пример прослеживаемого тест-кейса: 


щие пути 


1. Запустить приложение со 
всеми тремя параметрами, 
значения которых указы- 
вают на несуществующие 
в файловой системе пути. 


Требо- 

р Модуль | Подмодуль Шаги Ожидаемые результаты 
вание 
ДС-2.4, |Стартер | Обработчик | Запускснекорректными па- |1. В консоли отображаются 
ДС-3.2 ошибок раметрами, несуществую-| нижеуказанные сообщения, 


приложение завершает ра- 
боту. Сообщения 

а. SOURCE_DIR: directory 

not exists or inaccessible. 

b. DESTINATION_DIR: 

directory not exists or 


inaccessible. 
с. ТОС ЕЕ МАМЕ: 
wrong file пате ог 


inaccessible path. 


Можно подумать, что этот тест-кейс затрагивает ДС-2 и ДС-3 целиком, но в поле «Требова- 
ние» есть вполне чёткая конкретизация, к тому же указанные модуль, подмодуль и сама логика 


тест-кейса устраняют оставшиеся сомнения. 


Некоторые авторы также подчёркивают, что прослеживаемость тест-кейса связана с его не- 
избыточностью 44} по отношению к другим тест-кейсам (намного проще дать ссылку на один 
уникальный тест-кейс, чем выбирать из нескольких очень похожих). 


Возможность повторного использования. Это свойство редко выполняется для низкоуров- 
невых тест-кейсов23}, но при создании высокоуровневых тест-кейсов{123} можно добиться Ta- 


ких формулировок, при которых: 


• тест-кейс будет пригодным к использованию с различными настройками тестируемого при- 


ложения и в различных тестовых окружениях; 
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• тест-кейс практически без изменений можно будет использовать для тестирования анало- 
гичной функциональности в других проектах или других областях приложения. 


Примером тест-кейса, который тяжело использовать повторно, может являться практически 
любой тест-кейс с высокой специфичностью. 

Не самым идеальным, но очень наглядным примером тест-кейса, который может быть легко 
использован в разных проектах, может служить следующий тест-кейс: 


Шаги Ожидаемые результаты 
Запуск, все параметры некорректны 1. Приложение запускается, после чего выво- 
1. Запустить приложение, указав в качестве! ДИТ сообщение с описанием сути проблемы 
всех параметров заведомо некорректные| < Каждым из параметров и завершает работу. 
значения. 


Повторяемость. Тест-кейс должен быть сформулирован таким образом, чтобы при много- 
кратном повторении он показывал одинаковые результаты. Это свойство можно разделить на 
два подпункта: 


• во-первых, даже общие формулировки, допускающие разные варианты выполнения 
тест-кейса, должны очерчивать соответствующие явные границы (например: «ввести 
какое-нибудь число» — плохо, «ввести целое число в диапазоне от -273 до +500 включитель- 
но» — хорошо); 

• действия (шаги) тест-кейса по возможности не должны приводить к необратимым 
(или сложно обратимым) последствиям (например: удалению данных, нарушению конфи- 
гурации окружения и т.д.) — не стоит включать в тест-кейс такие «разрушительные дей- 
ствия», если они не продиктованы явным образом целью тест-кейса; если же цель тест-кейса 
обязывает нас к выполнению таких действий, в самом тест-кейсе должно быть описание 
действий по восстановлению исходного состояния приложения (данных, окружения). 


Соответствие принятым шаблонам оформления и традициям. С шаблонами оформления, 
как правило, проблем не возникает: они строго определены имеющимся образцом или вообще 
экранной формой инструментального средства управления тест-кейсами. Что же касается тра- 
диций, то они отличаются даже в разных командах в рамках одной компании, и тут невозможно 
дать иного совета, кроме как «почитайте уже готовые тест-кейсы перед тем как писать свои». 

В данном случае обойдёмся без отдельных примеров, т.к. выше и без того приведено много 
правильно оформленных тест-кейсов, а что касается нарушений этого свойства, то они прямо 
или косвенно описаны в главе «Типичные ошибки при разработке чек-листов, тест-кейсов и на- 
боров тест-кейсов»!161). 
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2.4.6. НАБОРЫ ТЕСТ-КЕЙСОВ mamm 


ТЕРМИНОЛОГИЯ И ОБЩИЕ СВЕДЕНИЯ 


Набор тест-кейсов (test case suite?03, test suite, test set) — совокупность тест-кейсов, 
выбранных с некоторой общей целью или по некоторому общему признаку. Иногда 
в такой совокупности результаты завершения одного тест-кейса становятся входным 
состоянием приложения для следующего тест-кейса. 


Внимание! Из-за особенностей перевода очень часто вместо «набор тест-кейсов» го- 
ворят «тестовый сценарий». Формально это можно считать ошибкой, но это явление 
приобрело настолько широкое распространение, что стало вариантом нормы. 


Как мы только что убедились на примере множества отдельных тест-кейсов, крайне неудобно 
(более того, это ошибка!) каждый раз писать в каждом тест-кейсе одни и те же приготовления и 
повторять одни и те же начальные шаги. 

Намного удобнее объединить несколько тест-кейсов в набор или последовательность. И здесь 
мы приходим к классификации наборов тест-кейсов. 


В общем случае наборы тест-кейсов можно разделить на свободные (порядок выполнения 
тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен). 


Преимущества свободных наборов: 


e Тест-кейсы можно выполнять в любом удобном порядке, а также создавать «наборы внутри 
наборов». 

e Если какой-то тест-кейс завершился ошибкой, это не повлияет на возможность выполнения 
других тест-кейсов. 


Преимущества последовательных наборов: 


• Каждый следующий в наборе тест-кейс в качестве входного состояния приложения получа- 
ет результат работы предыдущего тест-кейса, что позволяет сильно сократить количество 
шагов в отдельных тест-кейсах. 

• Длинные последовательности действий куда лучше имитируют работу реальных пользова- 
телей, чем отдельные «точечные» воздействия на приложение. 


ПОЛЬЗОВАТЕЛЬСКИЕ СЦЕНАРИИ (СЦЕНАРИИ ИСПОЛЬЗОВАНИЯ) 


© 


В данном случае речь НЕ идёт о use cases (вариантах использования), представляющих 
собой форму требований{3}. Пользовательские сценарии как техника тестирования 
куда менее формализованы, хотя и могут строиться на основе вариантов использо- 
вания. 


К отдельному подвиду последовательных наборов тест-кейсов (или даже неоформленных 


идей тест-кейсов, таких, как пункты чек-листа) можно отнести пользовательские сценарии? 


04 


303 Test case suite (test suite, test set). A set of several test cases for а component ог system under test, where the post 
condition of one test is often used as the precondition for the next one. [ISTQB Glossary] 


304 A scenario is a hypothetical story, used to help a person think through a complex problem or system. [Cem Kaner, 
«An Introduction to Scenario Testing», http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf] 
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(или сценарии использования), представляющие собой цепочки действий, выполняемых поль- 
зователем в определённой ситуации для достижения определённой цели. 


Поясним это сначала на примере, не относящемся к «Конвертеру файлов». Допустим, поль- 
зователь хочет распечатать табличку на дверь кабинета с текстом «Идёт работа, не стучать!» 


Для этого ему нужно: 


1) Запустить текстовый редактор. 
2) Создать новый документ (если редактор не делает это самостоятельно). 


3) Набрать в документе текст. 


4) Отформатировать текст должным образом. 
5) Отправить документ на печать. 
6) Сохранить документ (спорно, но допустим). 


7) Закрыть текстовый редактор 


Вот мы и получили пользовательский сценарий, пункты которого могут стать основой ДЛЯ 
шагов тест-кейса или целого набора отдельных тест-кейсов. 


Сценарии могут быть достаточн 


о длинными и сложными, могут содержать внутри себя циклы 


и условные ветвления, но при всём этом они обладают рядом весьма интересных преимуществ: 


• Сценарии показывают реальные и понятные примеры использования продукта (в отличие 
от обширных чек-листов, где смысл отдельных пунктов может теряться). 

• Сценарии понятны конечным пользователям и хорошо подходят для обсуждения и совмест- 
ного улучшения. 

• Сценарии и их части легче оценивать с точки зрения важности, чем отдельные пункты (осо- 
бенно низкоуровневых) требований. 

e Сценарии отлично показывают недоработки в требованиях (если становится непонятно, 
что делать в том или ином пункте сценария, — с требованиями явно что-то не то). 

• В предельном случае (нехватка времени и прочие форс-мажоры) сценарии можно даже не 
прописывать подробно, а просто именовать — и само наименование уже подскажет опыт- 
ному специалисту, что делать. 


Последний пункт проиллюстрируем на примере. Классифицируем потенциальных пользова- 


телей нашего приложения (напомним, что в нашем случае «пользователь» — это администратор, 
настраивающий работу приложения) по степени квалификации и склонности к экспериментам, 
а затем дадим каждому «виду пользователя» запоминающееся имя. 


Таблица 2.4.а — Классификация пользователей 


Низкая квалификация Высокая квалификация 


Не склонен к экспериментам 


«Осторожный» «Консервативный» 


Склонен к экспериментам 


«Отчаянный» 


«Изощрённый» 


Согласитесь, уже на этой стадии не составляет труда представить себе отличия в логике рабо- 


ты с приложением, например, «консервативного» и «отчаянного» пользователей. 


Но мы пойдём дальше и озаглавим для них сами сценарии, например, в ситуациях, когда такой 


пользователь позитивно и негативно относится к идее внедрения нашего приложения: 


Таблица 2.4.6 — Сценарии поведения на основе классификации пользователей 


«Осторожный» | «Консервативный» | «Отчаянный» | «Изощрённый» 
«А можно «Начнём «Гляньте, «Я всё оптими- 
Позитивно 
вот так?» с инструкции!» что я придумал!» |зирую!» 
«Я ничего «У вас вот здесь «Всё равно 
Негативно «А я говорил!» 
не понимаю.» несоответствие...» | поломаю!» 
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Проявив даже самую малость воображения, можно представить, что и как будет происходить 
в каждой из получившихся восьми ситуаций. Причём на создание пары таких таблиц уходит все- 
го несколько минут, а эффект от их использования на порядки превосходит бездумное «кликанье 
по кнопкам в надежде найти баг». 


как его применять и выполнять должным образом, можно прочесть в статье Сэма Ка- 


© Куда более полное и техничное объяснение того, что такое сценарное тестирование, 
нера «Ап Introduction to Scenario Теѕїпо»305. 


ПОДРОБНАЯ КЛАССИФИКАЦИЯ НАБОРОВ ТЕСТ-КЕЙСОВ 


© 


Подробная классификация наборов тест-кейсов может быть выражена следующей таблицей. 


Представленный здесь материал сложно отнести к категории «для начинающих» (и вы 
можете сразу перейти к пункту «Принципы построения наборов тест-кейсов» (151). 
Но если вам любопытно, взгляните на подробную классификацию, которая представ- 
лена ниже. 


Таблица 2.4.с — Подробная классификация наборов тест-кейсов 


По изолированности тест-кейсов друг от друга 
Изолированные Обобщённые 
По образованию Изолированные Обобщённые 
И Свободные 
тест-кейсами свободные свободные 
строгой Изолированные Обобщённые 
Последовательные 
последовательности последовательные последовательные 


e Набор изолированных свободных тест-кейсов (рисунок 2.4.9): действия из раздела «приго- 
товления» нужно повторить перед каждым тест-кейсом, а сами тест-кейсы можно выпол- 
нять в любом порядке. 

e Набор обобщённых свободных тест-кейсов (рисунок 2.4.1): действия из раздела «приготов- 
ления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а сами тест-кей- 
сы можно выполнять в любом порядке. 

e Набор изолированных последовательных тест-кейсов (рисунок 2.4.1): действия из раздела 
«приготовления» нужно повторить перед каждым тест-кейсом, а сами тест-кейсы нужно вы- 
полнять в строго определённом порядке. 

e Набор обобщённых последовательных тест-кейсов (рисунок 2.4.]): действия из раздела 
«приготовления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а сами 
тест-кейсы нужно выполнять в строго определённом порядке. 


Главное преимущество изолированности: каждый тест-кейс выполняется в «чистой среде», 
на него не влияют результаты работы предыдущих тест-кейсов. 

Главное преимущество обобщённости: приготовления не нужно повторять (экономия вре- 
мени). 

Главное преимущество последовательности: ощутимое сокращение шагов в каждом тест-кей- 
се, т. к. результат выполнения предыдущего тест-кейса является начальной ситуацией для сле- 
дующего. 

Главное преимущество свободы: возможность выполнять тест-кейсы в любом порядке, а так- 
же то, что при провале некоего тест-кейса (приложение не пришло в ожидаемое состояние) 
остальные тест-кейсы по-прежнему можно выполнять. 


305 «Ап Introduction to Scenario Testing», Сет Kaner [http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf] 
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Приготовления 


Тест 1 


Приготовления 


Рисунок 2.4.9 — Набор изолированных Рисунок 2.4.й — Набор обобщённых 
свободных тест-кейсов свободных тест-кейсов 
: | Приготовления 
; Приготовления | 
Тест 1 : 


Приготовления | : АЛ 
| : Тест 2 
Тест 2 О] 


Приготовления 
Тест 3 
Рисунок 2.4.1 — Набор изолированных Рисунок 2.4.ј — Набор обобщённых 
последовательных тест-кейсов последовательных тест-кейсов 


ПРИНЦИПЫ ПОСТРОЕНИЯ НАБОРОВ ТЕСТ-КЕЙСОВ 


Теперь — о самом главном: как формировать наборы тест-кейсов. Правильный ответ звучит 
очень кратко: логично. И это не шутка. Единственная задача наборов — повысить эффективность 
тестирования за счёт ускорения и упрощения выполнения тест-кейсов, увеличения глубины ис- 
следования некоей области приложения или функциональности, следования типичным пользо- 
вательским сценариям 48} или удобной последовательности выполнения тест-кейсов и т.д. 

Набор тест-кейсов всегда создаётся с какой-то целью, на основе какой-то логики, и по этим же 
принципам в набор включаются тесты, обладающие подходящими свойствами. 

Если же говорить [0] наиболее типичных подходах к составлению наборов тест-кейсов, ТО МОЖ- 
но обозначить следующее: 

° На основе чек-листов. Посмотрите внимательно на примеры чек-листов 118}, которые мы 

разработали в соответствующем разделе 17}: каждый пункт чек-листа может превратиться 
в несколько тест-кейсов — M BOT МЫ получаем готовый набор. 
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На основе разбиения приложения на модули и подмодули!!27). Для каждого модуля (или его 
отдельных подмодулей) можно составить свой набор тест-кейсов. 

По принципу проверки самых важных, менее важных и всех остальных функций приложе- 
ния (именно по этому принципу мы составляли примеры чек-листов 18}. 

По принципу группировки тест-кейсов для проверки некоего уровня требований или типа 
требований{ 3}, группы требований или отдельного требования. 

По принципу частоты обнаружения тест-кейсами дефектов в приложении (например, 
мы видим, что некоторые тест-кейсы раз за разом завершаются неудачей, значит, мы можем 
объединить их в набор, условно названный «проблемные места в приложении»). 

По архитектурному принципу (см. «многоуровневая архитектура»! самостоятельно): Ha- 
боры для проверки пользовательского интерфейса и всего уровня представления, для про- 
верки уровня бизнес-логики, для проверки уровня данных. 

По области внутренней работы приложения, например: «тест-кейсы, затрагивающие работу 
с базой данных», «тест-кейсы, затрагивающие работу с файловой системой», «тест-кейсы, 
затрагивающие работу с сетью», и ит.д. 

По видам тестирования (см. главу «Подробная классификация тестирования» (68)). 


Не нужно заучивать этот список. Это всего лишь примеры — грубо говоря, «первое, что при- 
ХОДИТ В голову». Важен принцип: если вы видите, что выполнение некоторых тест-кейсов в виде 
набора принесёт вам пользу, создавайте такой набор. 

Примечание: без хороших инструментальных средств управления тест-кейсами работать с 
наборами тест-кейсов крайне тяжело, т. к. приходится самостоятельно следить за приготовле- 
ниями, «недостающими шагами», изолированностью или обобщённостью, свободностью или 
последовательностью и т.д. 
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2.4.7. ЛОГИКА СОЗДАНИЯ 
ЭФФЕКТИВНЫХ ПРОВЕРОК mamm 


Теперь, когда мы рассмотрели принципы построения чек-листові!17) и оформления тест-кей- 
сов126}, свойства качественных тест-кейсов138}, а также принципы объединения тест-кейсов B 
наборы; настало время перейти к самой сложной, «философской» части, в которой мы будем 
рассуждать уже не о том, что и как писать, а о том, как думать. 

Ранее уже было сказано: если у тест-кейса не указаны входные данные, условия выполнения и 
ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс. И здесь во главе 
угла стоит цель. Если мы чётко понимаем, что и зачем мы делаем, мы или быстро находим всю 
остальную недостающую информацию, или столь же быстро формулируем правильные вопросы 
и адресуем их правильным людям. 


Вся суть работы тестировщика в конечном итоге направлена на повышение качества (процес- 
сов, продуктов и т. д.) Но что такое качество? Да, существует сухое официальное определение306, 
но даже там сказано про «user/customer needs and expectations» (потребности и ожидания поль- 
зователя/заказчика). 

И здесь проявляется главная мысль: качество — это некая ценность для конечного поль- 
зователя (заказчика). Человек в любом случае платит за использование продукта — деньгами, 
своим временем, какими-то усилиями (даже если вы не получаете эту «оплату», человек вполне 
обоснованно считает, что что-то уже на вас потратил, и он прав). Но получает ли он то, на что 
рассчитывал (предположим, что его ожидания — здравы и реалистичны)? 

Если мы подходим к тестированию формально, мы рискуем получить продукт, который по 
документам (метрикам и т.д.) выглядит идеально, но в реальности никому не нужен. 

Поскольку практически любой современный программный продукт представляет собой не- 
простую систему, среди широкого множества её свойств и функций объективно есть самые важ- 
ные, менее важные и совсем незначительные по важности для пользователей. 

Если усилия тестировщиков будут сконцентрированы на первой и второй категории (самом 
важном и чуть менее важном), наши шансы создать приложение, удовлетворяющее заказчика, 
резко увеличиваются. 


Есть простая логика: 


• Тесты ищут ошибки. 
• Но все ошибки найти невозможно. 
• Значит, наша задача — найти максимум ВАЖНЫХ ошибок за имеющееся время. 


Под важными ошибками здесь мы понимаем такие, которые приводят к нарушению важных 
для пользователя функций или свойств продукта. Функции и свойства разделены не случайно — 
безопасность, производительность, удобство и т.д. не относятся к функциям, но играют ничуть 
не менее важную роль в формировании удовлетворённости заказчика и конечных пользователей. 

Ситуация усугубляется следующими фактами: 


• всилу множества экономических и технических причин мы не можем выполнить «все тесты, 
что придут нам в голову» (да ещё и многократно) — приходится тщательно выбирать, что 
и как мы будем тестировать, принимая во внимание только что упомянутую мысль: каче- 
ство — это некая ценность для конечного пользователя (заказчика); 


306 Quality. The degree to which а component, system ог process meets specified requirements and/or user/customer needs 
and expectations. [ISTQB Glossary] 
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• никогда В реальной жизни (как бы мы ни старались) мы не получим «совершенного и иде- 
ального набора требований» — там всегда будет некоторое количество недоработок, и это 
тоже надо принимать во внимание. 


Однако существует достаточно простой алгоритм, позволяющий нам создавать эффективные 
проверки даже в таких условиях. Приступая к продумыванию чек-листа, тест-кейса или набора 
тест-кейсов, задайте себе следующие вопросы и получите чёткие ответы: 


• Что перед вами? Если вы не понимаете, что вам предстоит тестировать, вы не уйдёте дальше 
бездумных формальных проверок. 

e Кому и зачем оно нужно (и насколько это важно)? Ответ на этот вопрос позволит вам бы- 
стро придумать несколько характерных сценариев использования{148} того, что вы соби- 
раетесь тестировать. 

e Как оно обычно используется? Это уже детализация сценариев и источник идей для пози- 
тивного тестирования! 3} (их удобно оформить в виде чек-листа). 

e Как оно может сломаться, т. е. начать работать неверно? Это также детализация сценариев 
использования, но уже в контексте негативного тестирования! 3} (их тоже удобно оформить 
в виде чек-листа). 


К этому алгоритму можно добавить ещё небольшой перечень универсальных рекомендаций, 
которые позволят вам проводить тестирование лучше: 


e Начинайте как можно раньше — уже с момента появления первых требований можно 34- 
ниматься их тестированием и улучшением, можно писать чек-листы и тест-кейсы, можно 
уточнять план тестирования, готовить тестовое окружение ит.д. 

e Если вам предстоит тестировать что-то большое и сложное, разбивайте его на модули и под- 
модули, функциональность подвергайте функциональной декомпозиции3 07 — т.е. добей- 
тесь такого уровня детализации, при котором вы можете без труда удержать в голове всю 
информацию об объекте тестирования. 

e Обязательно пишите чек-листы. Если вам кажется, что вы сможете запомнить все идеи и 
потом легко их воспроизвести, вы ошибаетесь. Исключений не бывает. 

e По мере создания чек-листов, тест-кейсов и т.д. прямо в текст вписывайте возникающие 
вопросы. Когда вопросов накопится достаточно, соберите их отдельно, уточните формули- 
ровки и обратитесь к тому, кто может дать ответы. 

e Если используемое вами инструментальное средство позволяет использовать косметиче- 
ское оформление текста — используйте (так текст будет лучше читаться), но старайтесь 
следовать общепринятым традициям и не раскрашивать каждое второе слово в свой цвет, 
шрифт, размер и т.д. 

e Используйте технику беглого просмотра} для получения отзыва от коллег и улучшения 
созданного вами документа. 

• Планируйте время на улучшение тест-кейсов (исправление ошибок, доработку по факту из- 
менения требований ит. д.). 

e Начинайте проработку (и выполнение) тест-кейсов с простых позитивных проверок наибо- 
лее важной функциональности. Затем постепенно повышайте сложность проверок, помня 
не только о позитивных! 3}, но и о негативных{3} проверках. 

• Помните, что в основе тестирования лежит цель. Если вы не можете быстро и просто сфор- 
мулировать цель созданного вами тест-кейса, вы создали плохой тест-кейс. 

e Избегайте избыточных, дублирующих друг друга тест-кейсов. Минимизировать их количе- 
ство вам помогут техники классов эквивалентности 6}, граничных условий{6}, доменного 
тестирования”). 


307 «Functional decomposition», Wikipedia [http://en.wikipedia.org/wiki/Functional_decomposition] 
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e Если показательность! 42} тест-кейса можно увеличить, при этом не сильно изменив его 
сложность и не отклонившись от исходной цели, сделайте это. 

e Помните, что очень многие тест-кейсы требуют отдельной подготовки, которую нужно опи- 
сать в соответствующем поле тест-кейса. 

e Несколько позитивных тест-кейсов{83} можно безбоязненно объединять, но объединение 
негативных тест-кейсов{83} почти всегда запрещено. 

• Подумайте, как можно оптимизировать созданный вами тест-кейс (набор тест-кейсов ит. д.) 
так, чтобы снизить трудозатраты на его выполнение. 

e Перед тем как отправлять финальную версию созданного вами документа, ещё раз перечи- 
тайте написанное (в доброй половине случаев найдёте опечатку или иную недоработку). 


Задание 2.4.е: дополните этот список идеями, которые вы почерпнули из других книг, 
статей и т.д. 


ПРИМЕР РЕАЛИЗАЦИИ ЛОГИКИ СОЗДАНИЯ ЭФФЕКТИВНЫХ ПРОВЕРОК 


Ранее мы составили подробный чек-листі!17) для тестирования нашего «Конвертера фай- 
лов»{59). Давайте посмотрим на него критически и подумаем: что можно сократить, чем мы в 
итоге пожертвуем и какой выигрыш получим. 

Прежде чем мы начнём оптимизировать чек-лист, важно отметить, что решение о том, что 
важно и что неважно, стоит принимать на основе ранжирования требований по важности, атак- 
же согласовывать с заказчиком. 

Что для пользователя САМОЕ важное? Ради чего создавалось приложение? Чтобы конверти- 
ровать файлы. Принимая во внимание тот факт, что настройку приложения будет выполнять 
квалифицированный технический специалист, мы можем даже «отодвинуть на второй план» ре- 
акцию приложения на ошибки стадии запуска и завершения. 


И на первое место выходит: 


• Обработка файлов, разные форматы, кодировки и размеры: 


Таблица 2.4.4 — Форматы, кодировки и размеры файлов 


Форматы входных файлов 
TXT HTML MD 
WIN1251 100 KB 50 MB 10 MB 
CP866 10 MB 100 KB 50 MB 
Кодировки KOI8R 50 MB 10 MB 100 KB 
входных Любая 0 байт 
файлов Любая 50 МБ+1Б | 50МБ+1Б 50 МБ+1Б 
- Любой недопустимый формат 
Любая Повреждения в допустимом формате 


Можем ли мы как-то ускорить выполнение этих проверок (ведь их много)? Можем. И у нас 
даже есть два взаимодополняющих инструмента: 

• дальнейшая классификация по важности; 

• автоматизация тестирования. 


Сначала поделим таблицу на две — чуть более важное и чуть менее важное. 
В «чуть более важное» попадает: 
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Таблица 2.4.е — Форматы, кодировки и размеры файлов 
Форматы входных файлов 
TXT HTML MD 
Кодировки WIN1251 100 KB 50 MB 10 MB 
входных СР866 10 МБ 100 КБ 50 МБ 
файлов KOI8R 50 MB 10 MB 100 KB 


Подготовим 18 файлов — 9 исходных + 9 сконвертированных (в любом текстовом редакторе с 
функцией конвертации кодировок), чтобы в дальнейшем сравнивать работу нашего приложения 


с эталоном. 


Для «чуть менее важного» осталось: 


e Файл размером 0 байт (объективно для него не важна такая характеристика, как «коди- 
ровка»). Подготовим один файл размером 0 байт. 
• Файл размером 50 МБ + 1 Б (для него тоже не важна кодировка). Подготовим один файл 


размером 52’428’801 байт. 
• Любой недопустимый формат: 


° По расширению (файл с расширением, отличным от .txt, .html, тпа). Берём любой произ- 
вольный файл, например картинку (размер от 1 до 50 МБ, расширение .]ре). 

e Повнутреннему содержанию (например, .jpg переименовали в txt). Копии файла из npe- 
дыдущего пункта даём расширение txt. 


• Повреждения в допустимом формате. Вычёркиваем. Вообще. Даже крайне сложные дорогие 
редакторы далеко не всегда способны восстановить повреждённые файлы своих форматов, 
наше же приложение — это просто миниатюрная утилита конвертации кодировок, и не 
стоит ждать от неё возможностей профессионального инструментального средства вос- 
становления данных. 


Что мы получили в итоге? Нам нужно подготовить следующие 22 файла (поскольку у файлов 
всё равно есть имена, усилим этот набор тестовых данных, представив в именах файлов символы 
латиницы, кириллицы и спецсимволы). 


Таблица 2.4.} — Итоговый набор файлов для тестирования приложения 


№ Имя Кодировка Размер 
1 |«Мелкий» файл в WIN1251.txt WIN1251 100 KB 
2 |«Средний» файл в CP866.txt СР866 10 МБ 
3 «Крупный» файл в КОІ8К.іхі KOI8R 50 MB 
4 |«Крупный» файл s win-1251.html М М1251 50 МБ 
5 «Мелкий» файл в ср-866.Б СР866 100 КБ 
6 | «Средний» файл в koi8-r.html КОІВ8К 10 МБ 
7 |«Средний» файл в WIN_1251.md WIN1251 10 MB 
8 «Крупный» файл в CP_866.md СР866 50 МБ 
9 «Мелкий» файл в КОІ8 К.та KOI8R 100 KB 
10 |«Мелкий» эталон WIN1251.txt UTF8 100 КБ 
11 |«Средний» эталон CP866.txt UTF8 10 MB 
12 |«Крупный» эталон KOI8R.txt UTF8 50 MB 
13 |«Крупный» эталон в win-1251.html UTF8 50 MB 
14 |«Мелкий» эталон в cp-866.html UTF8 100 KB 
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Таблица 2.4. [окончание] 


№ Имя Кодировка Размер 
15 |«Средний» эталон в koi8-r.html ОТЕ8 10 МБ 

16 |«Средний» эталон в WIN_1251.md UTF8 10 MB 

17 |«Крупный» эталон в CP_866.md UTF8 50 MB 

18 |«Мелкий» эталон B KOI8_R.md UTF8 100 KB 

19 |Пустой файл.та - ОБ 

20 |Слишком большой файл.їхі - 52428801 Б 
21 |Картинка.јре - ~ 1 MB 

22 |Картинка в виде TXT.txt - ~ 1 МБ 


И только что мы упомянули автоматизацию как способ ускорения выполнения тест-кейсов. 
В данном случае мы можем обойтись самыми тривиальными командными файлами. В прило- 
жении «Командные файлы для Windows и Linux, автоматизирующие выполнение дымового TEC- 
тирования» {286} приведены скрипты, полностью автоматизирующие выполнение всего уровня 
дымового тестирования{80} над представленным выше набором из 22 файлов. 


чтобы их выполнение заодно проверяло работу тестируемого приложения с пробела- 
ми, кириллическими символами и спецсимволами в путях к входному каталогу, выход- 
ному каталогу и файлу журнала. Оптимизируйте получившиеся командные файлы так, 
чтобы избежать многократного дублирования кода. 


© Задание 2.4.Ё доработайте представленные в приложении!86} командные файлы так, 


Если снова вернуться к чек-листу, то оказывается, что мы уже подготовили проверки для всего 
уровня дымового тестирования{80} и части уровня тестирования критического пути!81. 

Продолжим оптимизацию. Большинство проверок не представляет особой сложности, и мы 
разберёмся с ними по ходу дела, но есть в чек-листе пункт, вызывающий особую тревогу: произ- 
водительность. 

Тестирование и оптимизация производительности? 3} — это отдельный вид тестирования со 
своими достаточно непростыми правилами и подходами, к тому же разделяющийся на несколько 
подвидов. Нужно ли оно нам в нашем приложении? Заказчик в АК-1.1 определил минимальную 
производительность приложения как способность обрабатывать входные данные со скоростью 
не менее 5 МБ/сек. Грубые эксперименты на указанном в АК-1.1 оборудовании показывают, что 
даже куда более сложные операции (например, архивирование видеофайла с максимальной сте- 
пенью сжатия) выполняются быстрее (пусть и ненамного). Вывод? Вычёркиваем. Вероятность 
встретить здесь проблему ничтожно мала, а соответствующее тестирование требует ощутимых 
затрат сил и времени, а также наличия соответствующих специалистов. 


Вернёмся к чек-листу: 
e Конфигурирование и запуск: 
° Е верными параметрами: 
" Значения SOURCE-ÐDIR DESFINAHON-DRR EOG 


HHO 


WS 


БҮ КИРУ ИЯ 


(Уже учтено при автоматизации проверки 


HTS 
KLS ELA cc >> 


работы приложения с 22 файлами.) 


" Значение -ӨЄ-ЕЊЕ-МАМЕ неуказано: (Объединить с проверкой ведения CAMO- 


го файла журнала.) 


° Без параметров. 
° С недостаточным количеством параметров. 


158 


Раздел 2: ОСНОВНЫЕ ЗНАНИЯ И УМЕНИЯ 


° С неверными параметрами: 


Недопустимый путь ЅООКСЕ РІК. 

Недопустимый путь ОЕЅТІМАТІОМ РІК. 
Недопустимое имя ОС _ЕПЕ МАМЕ. 
DESTINATION_DIR находится внутри ЅООКСЕ ШІК. 


= Значения РЕЅТІЧАТІОМ ПІК и SOURCE_DIR совпадают. 


• Обработка файлов: 


Da 
9 а пБ олма 


° Недоступные входные файлы: 


" Нет прав доступа. 
" Файл открыт и заблокирован. 


: (Уже сделано.) 


" Файл сатрибутом «только для чтения». 


• Остановка: 


° Закрытиемокнаконсели: (Вычёркиваем. Не настолько важная проверка, а если и бу- 
дут проблемы — технология РНР не позволит их решить.) 


e Журнал работы приложения: 


° Автоматическое создание (при отсутствии журнала), имя журнала указано явно. 
° Продолжение (дополнение журнала) при повторных запусках, имя журнала не указано. 


• Нроизводительность: 


° Элементарный тестс трубой оценкой: (Ранее решили, что наше приложение явно уло- 


жится в весьма демократичные требования заказчика.) 


Перепишем компактно то, что у нас осталось от уровня тестирования критического пути{81. 
Внимание! Это — НЕ тест-кейс! Это всего лишь ещё одна форма записи чек-листа, более удобная 


на данном этапе. 


Таблица 2.4.9 — Чек-лист для уровня критического пути 


Суть проверки 


Ожидаемая реакция 


Запуск без параметров. 


Отображение инструкции к использованию. 


Запуск с недостаточным количеством пара- 
метров. 


Отображение инструкции к использованию и 
указание имён недостающих параметров. 


Запуск с неверными значениями параметров: 


e Недопустимый путь SOURCE_DIR. 

° Недопустимый путь DESTINATION_DIR. 

° Недопустимое имя LOG_FILE_NAME. 

DESTINATION_DIR находится внутри 

SOURCE_DIR. 

о Значения DESTINATION_DIR и SOURCE_ 
DIR совпадают. 


© 


Отображение инструкции к использованию 
и указание имени неверного параметра, зна- 
чения неверного параметра и пояснения сути 
проблемы. 


Недоступные входные файлы: 


° Нет прав доступа. 

° Файл открыт и заблокирован. 

° Файл с атрибутом «только для чтения». 
Журнал работы приложения: 


° Автоматическое создание (при отсутствии 
журнала), имя журнала указано явно. 

° Продолжение (дополнение журнала) при по- 
вторных запусках, имя журнала не указано. 


Отображение сообщения в консоль и файл 
журнала, дальнейшее игнорирование недо- 
ступных файлов. 


Создание или продолжение ведения файла 
журнала по указанному или вычисленному 
пути. 
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Наконец, у нас остался уровень расширенного тестирования!86). И сейчас мы сделаем то, чего 
по всем классическим книгам учат не делать, — мы откажемся от всего этого набора проверок 
целиком. 

• Конфигурирование и запуск: 

о Значения ЅӨЪВЄЕ-РН;-РЕЅТВЧАҒЮМРӘНЊБӨЄ-ЕЊЕ-МАМЕ: 
" В-разных-стилях-(Айпаоуғѕ-=тути-+—піх-пути) — одно-в- одном стиле, другое — 
в другом: 
" С использованием НЕ -имён. 
a БӨЄ-ЕЊЕ-МАМЕ внутри SOURCE-ÐR: 
a РӨЄ-ЕЊЕ-МАМЕ внутри DESHNATION DR: 
о Размер -ӨЄ-ЕЊЕ-МАМЕ-на-момент-запуска: 


° Запускдвух и болеекопий приложенияс: 
= Одинаковыми параметрами ЗОЗКЕЕ-РЕ; РЕЗЕНУАЕТЮМ РЕ; ЕБОв-ЕНЕЕ- 
NAME- 


= Одинаковыми бОУЗВЕЕ-БЕ и tOG-FHE-NAME но разными DESHNAHON-— 


Да, мы сейчас действительно повысили риск пропустить какой-то дефект. Но — дефект, веро- 
ятность возникновения которого мала в силу малой вероятности возникновения описанных в 
этих проверках ситуаций. При этом по самым скромным прикидкам мы на треть сократили об- 
щее количество проверок, которые нам нужно будет выполнять, а значит — высвободили силы и 
время для более тщательной проработки типичных каждодневных сценариев использования 48} 
приложения. 


Весь оптимизированный чек-лист (он же — и черновик для плана выполнения проверок) те= 
перь выглядит так: 


1) Подготовить файлы (см. таблицу 2.4.Р). 

2) Для «дымового теста» использовать командные файлы (см. приложение «Командные фай- 
лы для Windows и Linux, автоматизирующие выполнение дымового тестирования» {286}). 

3) Для основных проверок использовать файлы из пункта 1 и следующие идеи (таблица 2.4.Һ). 
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Таблица 2.4. — Основные проверки для приложения «Конвертер файлов» 


Суть проверки 


Ожидаемая реакция 


Запуск без параметров. 


Отображение инструкции к использованию. 


Запуск с недостаточным количеством пара- 
метров. 


Отображение инструкции к использованию и 
указание имён недостающих параметров. 


Запуск с неверными значениями параметров: 


° Недопустимый путь SOURCE_DIR. 

° Недопустимый путь DESTINATION_DIR. 

° Недопустимое имя ОС ЕПЕ МАМЕ. 

РЕЅТІМАТІОМ ЮІК находится внутри 

ЅООКСЕ, РІК. 

о Значения РЕЅТІЛМАТІОМ РІК и SOURCE_ 
DIR совпадают. 


о 


Отображение инструкции к использованию 
и указание имени неверного параметра, зна- 
чения неверного параметра и пояснения сути 
проблемы. 


Недоступные входные файлы: 


° Нет прав доступа. 
° Файл открыт и заблокирован. 
° Файл сатрибутом «только для чтения». 


Отображение сообщения в консоль и файл 
журнала, дальнейшее игнорирование недо- 
ступных файлов. 


Журнал работы приложения: 


° Автоматическое создание (при отсутствии 
журнала), имя журнала указано явно. 

° Продолжение (дополнение журнала) при по- 
вторных запусках, имя журнала не указано. 


Создание или продолжение ведения файла 
журнала по указанному или вычисленному 
пути. 


4) В случае наличия времени использовать первоначальную редакцию чек-листа для уровня 
расширенного тестирования{82} как основу для выполнения исследовательского тестиро- 


вания{87}. 


И почти всё. Остаётся только ещё раз подчеркнуть, что представленная логика выбора про- 
верок не претендует на то, чтобы считаться единственно верной, но она явно позволяет сэко- 
номить огромное количество усилий, при этом практически не снизив качество тестирования 
наиболее востребованной заказчиком функциональности приложения. 


© 


Задание 2.4.5: подумайте, какие проверки из таблицы 2.4.6 можно автоматизировать с 
помощью командных файлов. Напишите такие командные файлы. 
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2.4.8. ТИПИЧНЫЕ ОШИБКИ ПРИ РАЗРАБОТКЕ 
ЧЕК-ЛИСТОВ, ТЕСТ-КЕИСОВ 
И НАБОРОВ ТЕСТ-КЕИСОВ таии 


ОШИБКИ ОФОРМЛЕНИЯ И ФОРМУЛИРОВОК 


Отсутствие заглавия тест-кейса или плохо написанное заглавие. В абсолютном большинстве 
систем управления тест-кейсами поле для заглавия вынесено отдельно и является обязательным 
к заполнению — тогда эта проблема отпадает. Если же инструментальное средство позволяет 
создать тест-кейс без заглавия, возникает риск получить М тест-кейсов, для понимания сути 
каждого из которых нужно прочитать десятки строк вместо одного предложения. Это гаран- 
тированное убийство рабочего времени и снижение производительности команды на порядок. 

Если заглавие тест-кейса приходится вписывать в поле с шагами и инструментальное средство 
допускает форматирование текста, заглавие стоит писать жирным шрифтом, чтобы его было 
легче отделять от основного текста. 

Продолжением этой ошибки является создание одинаковых заглавий, по которым объектив- 
но невозможно отличить один тест-кейс от другого. Более того, возникает подозрение, что оди- 
наково озаглавленные тест-кейсы и внутри одинаковы. Потому следует формулировать загла- 
вия по-разному, при этом подчёркивая в них суть тест-кейса и его отличие от других, похожих 
тест-кейсов. 

И, наконец, в заглавии недопустимы «мусорные слова» вида «проверка», «тест» и т. д. Ведь это 
заглавие тест-кейса, т.е. речь по определению идёт о проверке, и не надо этот факт подчёркивать 
дополнительно. Также см. более подробное пояснение этой ошибки ниже в пункте «Постоянное 
использование слов «проверить» (и ему подобных) в чек-листах». 


Отсутствие нумерации шагов и/или ожидаемых результатов (даже если таковой всего лишь 
один). Наличие этой ошибки превращает тест-кейс в «поток сознания», в котором нет структу- 
рированности, модифицируемости и прочих полезных свойств (да, многие свойства качествен- 
ных требований 4} в полной мере применимы и к тест-кейсам) — становится очень легко пере- 
путать, что к чему относится. Даже выполнение такого тест-кейса усложняется, а доработка и 
вовсе превращается в каторжный труд. 


Ссылка на множество требований. Иногда высокоуровневый тест-кейс!123) действительно 
затрагивает несколько требований, но в таком случае рекомендуется писать ссылку на максимум 
2-3 самых ключевых (наиболее соответствующих цели тест-кейса), а ещё лучше — указывать 
общий раздел этих требований (т.е. не ссылаться, например, на требования 5.7.1, 5.7.2, 5.7.3, 5.7.7, 
5.7.9, 5.7.12, а просто сослаться на раздел 5.7, включающий в себя все перечисленные пункты). 
В большинстве инструментальных средств управления тест-кейсами это поле представляет со- 
бой выпадающий список, и там эта проблема теряет актуальность. 


Использование личной формы глаголов. Если вы пишете требования на русском, то пиши- 
те «нажать» вместо «нажмите», «ввести» вместо «введите», «перейти» вместо «перейдите» и т.д. 
В технической документации вообще не рекомендуется «переходить на личности», а также суще- 
ствует мнение, что личная форма глаголов подсознательно воспринимается как «чужие бессмыс- 
ленные команды» и приводит к повышенной утомляемости и раздражительности. 


Использование прошедшего или будущего времени в ожидаемых результатах. Это не очень 
серьёзная ошибка, но всё равно «введённое значение отображается в поле» читается лучше, чем 
«введённое значение отобразилось в поле» или «введённое значение отобразится в поле». 
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Постоянное использование слов «проверить» (и ему подобных) в чек-листах. В итоге почти 
каждый пункт чек-листа начинается с «проверить ...», «проверить...», «проверить...». Но ведь 
весь чек-лист — это и есть список проверок! Зачем писать это слово? Сравните: 


Плохо Хорошо 
Проверить запуск приложения. Запуск приложения. 
Проверить открытие корректного файла. Открытие корректного файла. 
Проверить модификацию файла. Модификация файла. 
Проверить сохранение файла. Сохранение файла. 
Проверить закрытие приложения. Закрытие приложения. 


Сюда же относится типичное слово «попытаться» в негативных тест-кейсах («попытаться по- 
делить на ноль», «попытаться открыть несуществующий файл», «попытаться ввести недопусти- 
мые символы»): «деление на ноль», «открытие несуществующего файла», «ввод спецсимволов» 
намного короче и информативнее. А реакцию приложения, если она не очевидна, можно ука- 
зать в скобках (так будет даже информативнее): «деление на ноль» (сообщение «Division Бу zero 
detected»), «открытие несуществующего файла» (приводит к автоматическому созданию файла), 
«ввод спецсимволов» (символы не вводятся, отображается подсказка). 


Описание стандартных элементов интерфейса вместо использования их устоявшихся на- 
званий. «Маленький крестик справа вверху окна приложения» — это системная кнопка «За- 
крыть» (system button «С]озе»), «быстро-быстро дважды нажать на левую клавишу мыши» — 
это двойной щелчок (double click), «маленькое окошечко с надписью появляется, когда наводишь 
мышь» — это всплывающая подсказка (hint). 


Пунктуационные, орфографические, синтаксические и им подобные ошибки. Без коммен- 
тариев. 


ЛОГИЧЕСКИЕ ОШИБКИ 


Ссылка на другие тест-кейсы или шаги других тест-кейсов. За исключением случаев написа- 
ния строго оговорённого явно обозначенного набора последовательных тест-кейсов{150} это 3a- 
прещено делать. В лучшем случае вам повезёт, и тест-кейс, на который вы ссылались, будет про- 
сто удалён — повезёт потому, что это будет сразу заметно. Не повезёт в случае, если тест-кейс, 
на который вы ссылаетесь, будет изменён — ссылка по-прежнему ведёт в некое существующее 
место, но описано там уже совершенно не то, что было в момент создания ссылки. 


Детализация, не соответствующая уровню функционального тестирования! 0}. Например, 
не нужно на уровне дымового тестирования{0} проверять работоспособность каждой отдель- 
ной кнопки или прописывать некий крайне сложный, нетривиальный и редкий сценарий — по- 
ведение кнопок и без явного указания будет проверено множеством тест-кейсов, объективно 
задействующих эти кнопки, а сложному сценарию место на уровне тестирования критического 
пути или даже на уровне расширенного тестирования{?} (в которых, напротив, недостатком 
можно считать излишнее обобщение без должной детализации). 


Расплывчатые двусмысленные описания действий и ожидаемых результатов. Помните, что 
тест-кейс с высокой вероятностью будете выполнять не вы (автор тест-кейса), а другой сотруд- 
ник, и он — не телепат. Попробуйте догадаться по этим примерам, что имел в виду автор: 


e «Установить приложение на диск С». (Т. е. в «СЛ»? Прямо в корень? Или как?) 


• «Нажать на иконку приложения». (Например, если у меня есть ісо-файл с иконкой приложе- 
ния, ия по нему кликну — это оно? Или нет?) 
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„ «Окно приложения запустится». (Куда?) 

e «Работает верно». (Ого! А верно — это, простите, как?) 

• «ОК». (И? Что «ОК»?) 

» «Количество найденных файлов совпадает». (С чем?) 

e «Приложение отказывается выполнять команду». (Что значит «отказывается»? Как это вы- 
глядит? Что должно происходить?) 


Описание действий в качестве наименований модуля/подмодуля. Например, «запуск при- 


ложения» — это НЕ модуль или подмодуль. Модуль или подмодуль!27} — это всегда некие ча- 
сти приложения, а не его поведение. Сравните: «дыхательная система» — это модуль человека, 
но «дыхание» — нет. 


Описание событий или процессов в качестве шагов или ожидаемых результатов. Напри- 
мер, в качестве шага сказано: «Ввод спецсимволов в поле Х». Это было бы сносным заглавием 
тест-кейса, но не годится в качестве шага, который должен быть сформулирован как «Ввести 
спецсимволы (перечень) в поле Х». 

Куда страшнее, если подобное встречается в ожидаемых результатах. Например, там написано: 
«Отображение скорости чтения в панели Х». И что? Оно должно начаться, продолжиться, завер- 
шиться, не начинаться, неким образом измениться (например, измениться должна размерность 
данных), как-то на что-то повлиять? Тест-кейс становится полностью бессмысленным, т. к. такой 
ожидаемый результат невозможно сравнить с фактическим поведением приложения. 


«Выдумывание» особенностей поведения приложения. Да, часто в требованиях отсутству- 
ют самоочевидные (без кавычек, они на самом деле самоочевидные) вещи, но нередко встреча- 
ются и некачественные (например, неполные) требования, которые нужно улучшать, а не «теле- 
патически компенсировать». 

Например, в требованиях сказано, что «приложение должно отображать диалоговое окно 
сохранения с указанным по умолчанию каталогом». Если из контекста (соседних требований, 
иных документов) ничего не удаётся узнать об этом таинственном «каталоге по умолчанию», 
нужно задать вопрос. Нельзя просто записать в ожидаемых результатах «отображается диало- 
говое окно сохранения С указанным по умолчанию каталогом» (как мы проверим, что выбран 
именно указанный по умолчанию каталог, а не какой-то иной?). И уж тем более нельзя в ожида- 
емых результатах писать «отображается диалоговое окно сохранения С выбранным каталогом 
“C:/SavedDocuments”» (откуда взялось это «C:/SavedDocuments», — не ясно, т. е. оно явно выду- 
мано из головы И, скорее всего, выдумано неправильно). 


Отсутствие описания приготовления к выполнению тест-кейса. Часто для корректного вы- 
полнения тест-кейса необходимо каким-то особым образом настроить окружение. Предполо- 
жим, что мы проверяем приложение, выполняющее резервное копирование файлов. Если тест 
выглядит примерно так, то выполняющий его сотрудник будет в замешательстве, т. к. ожидае- 
мый результат кажется просто бредом. Откуда взялось «-200»? Что это вообще такое? 


Шаги выполнения Ожидаемые результаты 
1. Нажать на панели «Главная» кнопку «Бы- |1. Кнопка «Быстрая дедубликация» переходит 
страя дедубликация». в утопленное состояние и меняет цвет с серого 
2. Выбрать каталог «C:/MyData». на зелёный. 


2. На панели «Состояние» в поле «Дубликаты» 
отображается «~200». 


И совсем иначе этот тест-кейс воспринимался бы, если бы в приготовлениях было сказано: 
«Создать каталог “С:/Мураќа” с произвольным набором подкаталогов (глубина вложенности не 
менее пяти). В полученном дереве каталогов разместить 1000 файлов, из которых 200 имеют оди- 
наковые имена и размеры, но НЕ внутреннее содержимое». 
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Полное дублирование (копирование) одного и того же тест-кейса на уровнях дымового 
тестирования, тестирования критического пути, расширенного тестирования. Многие идеи 
естественным образом развиваются от уровня куровню!80), но они должны именно развиваться, 
а не дублироваться. Сравните: 


Дымовое тестирование Тестирование Расширенное тестирование 
критического пути 
Плохо |Запуск приложения. Запуск приложения. |Запуск приложения. 
Хорошо | Запуск приложения. Запуск приложения |Запуск приложения из командной 


из командной строки. | строки в активном режиме. 
Запуск приложения |Запуск приложения из командной 
через ярлык на рабо- |строки в фоновом режиме. 


чем столе. Запуск приложения через ярлык на 
Запуск приложения |рабочем столе от имени админи- 
через меню «Пуск». стратора. 


Запуск приложения через меню 
«Пуск» из списка часто запускае- 
мых приложений. 


Слишком длинный перечень шагов, не относящихся к сути (цели) тест-кейса. Например, 
мы хотим проверить корректность одностороннего режима печати из нашего приложения на 
дуплексном принтере. Сравните: 


Плохо Хорошо 
Односторонняя печать Односторонняя печать 
1. Запустить приложение. 1. Открыть любой РОСХ-файл, содержащий 
2. В меню выбрать «Файл» -> «Открыть». три и более непустых страницы. 
3. Выбрать любой РОСХ-файл, состоящий из|2.В диалоговом окне «Настройка печати» 
нескольких страниц. в списке «Двусторонняя печать» выбрать 
4. Нажать кнопку «Открыть». «Нет». 
5. В меню выбрать «Файл» -> «Печать». 3. Произвести печать документа на принтере, 
6.В списке «Двусторонняя печать» выбрать! поддерживающем двустороннюю печать. 
пункт «Нет». 
7. Нажать кнопку «Печать». 
8. Закрыть файл. 
9. Закрыть приложение. 


Слева мы видим огромное количество действий, не относящихся непосредственно к тому, что 
проверяет тест-кейс. Тем более что запуск и закрытие приложения, открытие файла, работа меню 
и прочее или будут покрыты другими тест-кейсами (со своими соответствующими целями), или 
на самом деле являются самоочевидными (логично ведь, что нельзя открыть приложением файл, 
если приложение не запущено) и не нуждаются в описании шагов, которые только создают ин- 
формационный шум и занимают время на написание и прочтение. 


Некорректное наименование элементов интерфейса или их свойств. Иногда из контек- 
ста понятно, что автор тест-кейса имел в виду, но иногда это становится реальной проблемой. 
Например, мы видим тест-кейс с заглавием «Закрытие приложения кнопками «Close» и «Close 
window»». Уже тут возникает недоумение по поводу того, в чём же различие этих кнопок, даи о 
чём вообще идёт речь. Ниже (в шагах тест-кейса) автор поясняет: «В рабочей панели внизу экра- 
на нажать «Close window»». Ага! Ясно. Но «Close window» — это НЕ кнопка, это пункт системного 
контекстного меню приложения в панели задач. 
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Ещё один отличный пример: «Окно приложения свернётся в окно меньшего диаметра». Хм. 
Окно круглое? Или должно стать круглым? А, может, тут и вовсе речь про два разных окна, 
и одно должно будет оказаться внутри второго? Или, всё же «размер окна уменьшается» (кстати, 
насколько?), а его геометрическая форма остаётся прямоугольной? 

И, наконец, пример, из-за которого вполне можно написать отчёт о дефекте на вполне коррек- 
тно работающее приложение: «В системном меню выбрать “Фиксация расположения”». Казалось 
бы, что ж тут плохого? Но потом выясняется, что имелось в виду главное меню приложения, а 
вовсе не системное меню. 


Непонимание принципов работы приложения и вызванная этим некорректность тест-кей- 
сов. Классикой жанра является закрытие приложения: тот факт, что окно приложения «исчезло» 
(сюрприз: например, оно свернулось в область уведомления панели задач (system tray, taskbar 
notification агеа)), или приложение отключило интерфейс пользователя, продолжив функциони- 
ровать в фоновом режиме, вовсе не является признаком того, что оно завершило работу. 


Проверка типичной «системной» функциональности. Если только ваше приложение не на- 
писано с использованием каких-то особенных библиотек и технологий и не реализует какое-то 
нетипичное поведение, нет необходимости проверять системные кнопки, системные меню, сво- 
рачивание-разворачивание окна и т.д. Вероятность встретить здесь ошибку стремится к нулю. 
Если всё же очень хочется, можно вписать эти проверки как уточнения некоторых действий 
на уровне тестирования критического пути! 1, но создавать для них отдельные тест-кейсы не 
нужно. 


Неверное поведение приложения как ожидаемый результат. Такое не допускается по опре- 
делению. Не может быть тест-кейса с шагом в стиле «поделить на ноль» с ожидаемым результа- 
том «крах приложения с потерей пользовательских данных». Ожидаемые результаты всегда опи- 
сывают правильное поведение приложения — даже в самых страшных стрессовых тест-кейсах. 


Общая некорректность тест-кейсов. Может быть вызвана множеством причин и выражаться 
множеством образов, но вот классический пример: 


Шаги выполнения Ожидаемые результаты 
4. Закрыть приложение нажатием Alt+F4. 4. Приложение завершает работу. 
5. Выбрать в меню «Текущее состояние». 5. Отображается окно с заголовком «Текущее 
состояние» и содержимым, соответствую- 
щим рисунку 999.99. 


Здесь или не указано, что вызов окна «Текущее состояние» происходит где-то в другом прило- 
жении, или остаётся загадкой, как вызвать это окно у завершившего работу приложения. Запу- 
стить заново? Возможно, но в тест-кейсе этого не сказано. 


Неверное разбиение наборов данных на классы эквивалентности. Действительно, иногда 
классы эквивалентности 6} могут быть очень неочевидными. Но ошибки встречаются и в до- 
вольно простых случаях. Допустим, в требованиях сказано, что размер некоего файла может 
быть от 10 до 100 КБ (включительно). Разбиение по размеру 0-9 КБ, 10-100 КБ, 101+ КБ ошибоч- 
но, т.к. килобайт не является неделимой единицей. Такое ошибочное разбиение не учитывает, 
например, размеры в 9.5 КБ, 100.1 КБ, 100.7 КБ ит.д. Потому здесь стоит применять неравенства: 
ОКБ < размер < 10 КБ, 10 КБ < размер < 100 КБ, 100 КБ < размер. Также можно писать с использо- 
ванием синтаксиса скобок: [0, 10) КБ, [10, 100] КБ, (100, œ) КБ, но вариант с неравенствами более 
привычен большинству людей. 


Тест-кейсы, не относящиеся к тестируемому приложению. Например, нам нужно проте- 
стировать фотогалерею на сайте. Соответственно, следующие тест-кейсы никак не относятся 
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к фотогалерее (они тестируют браузер, операционную систему пользователя, файловый мене- 
джер ит. д. — но НЕ наше приложение, ни его серверную, ни даже клиентскую часть): 

• Файл с сетевого диска. 

• Файл со съёмного носителя. 

e Файл, заблокированный другим приложением. 

• Файл, открытый другим приложением. 

» Файл, к которому у пользователя нет прав доступа. 

e Вручную указать путь к файлу. 

• Файл из глубоко расположенной поддиректории. 

Формальные и/или субъективные проверки. Чаще всего данную ошибку можно встретить 
в пунктах чек-листа. Возможно, у автора в голове и был чёткий и подробный план, но из сле- 
дующих примеров совершенно невозможно понять, что будет сделано с приложением, и какой 
результат мы должны ожидать: 

e «Сконвертировать». 

• «Проверить метод getMessage()». 

e «Некорректная работа в корректных условиях». 

» «Скорость». 

e «Объём данных». 

• «Должно работать быстро». 


В отдельных исключительных ситуациях МОЖНО возразить, что из контекста и дальнейшей де- 
тализации становится понятно, что имелось в виду. Но чаще всего никакого контекста и никакой 
дальнейшей детализации нет, т.е. приведённые примеры оформлены как отдельные полноправ- 
ные пункты чек-листа. Так — нельзя. Как можно И нужно — CM. B примере чек-листа{118) и всём 
соответствующем разделе\117}, 


Теперь для лучшего закрепления рекомендуется заново прочитать про оформление атрибутов 
тест-кейсов 26}, свойства качественных тест-кейсовї138} и логику построения!153} качественных 
тест-кейсов и качественных наборов тест-кейсов. 
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ОТЧЕТЫ 0 ДЕФЕКТАХ 


2.5.1. ОШИБКИ, ДЕФЕКТЫ, СБОИ, 
ОТКАЗЫ И Т.Д. тишина 


УПРОЩЁННЫЙ ВЗГЛЯД НА ПОНЯТИЕ ДЕФЕКТА 


Далее в этой главе мы глубоко погрузимся в терминологию (она действительно важна!), а по- 
тому начнём с очень простого: дефектом упрощённо можно считать любое расхождение ожи- 
даемого (свойства, результата, поведения и т.д., которое мы ожидали увидеть) и фактического 
(свойства, результата, поведения и т.д., которое мы на самом деле увидели). При обнаружении 
дефекта создаётся отчёт о дефекте. 


Z Дефект — расхождение ожидаемого и фактического результата. 
© Ожидаемый результат — поведение системы, описанное в требованиях. 


Фактический результат — поведение системы, наблюдаемое в процессе тестирования. 


2 ВАЖНО! Эти три определения приведены в предельно упрощённой (и даже искажён- 
@ ной) форме с целью первичного ознакомления. Полноценные формулировки см. далее 


в этой же главе. 


Поскольку столь простая трактовка не покрывает все возможные формы проявления проблем 
с программными продуктами, мы сразу же переходим к более подробному рассмотрению соот- 
ветствующей терминологии. 


РАСШИРЕННЫЙ ВЗГЛЯД НА ТЕРМИНОЛОГИЮ, ОПИСЫВАЮЩУЮ ПРОБЛЕМЫ 


Разберёмся с широким спектром синонимов, которыми обозначают проблемы с программны- 
ми продуктами и иными артефактами и процессами, сопутствующими их разработке. 

В силлабусе ISTQB написано?08, что человек совершает ошибки, которые приводят к возник- 
новению дефектов в коде, которые, в свою очередь, приводят к сбоям и отказам приложения 
(однако сбои и отказы могут возникать и из-за внешних условий, таких как электромагнитное 
воздействие на оборудование и т.д.) 


308 А human being can make ап error (mistake), which produces а defect (fault, bug) in the program code, ог in а document. 
If a defect in code is executed, the system may fail to do what it should do (or do something it shouldnt), causing a failure. 
Defects in software, systems or documents may result in failures, but not all defects do so. Defects occur because human beings 
are fallible and because there is time pressure, complex code, complexity of infrastructure, changing technologies, and/or many 
system interactions. Failures can be caused by environmental conditions as well. For example, radiation, magnetism, electronic 
fields, and pollution can cause faults in firmware or influence the execution of software by changing the hardware conditions. 
[ISTQB Syllabus] 
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Таким образом, упрощённо можно изобразить следующую схему: 


Сбой или отказ 


Рисунок 2.5.а — Ошибки, дефекты, сбои и отказы 


Если же посмотреть на англоязычную терминологию, представленную в глоссарии ISTQB и 
иных источниках, можно построить чуть более сложную схему: 


Defect 
Error (Mistake) (Problem, Bug, 
Fault) 


Failure, 
Interruption 


Anomaly, Incident (Deviation) 


Рисунок 2.5.b — Взаимосвязь проблем в разработке программных продуктов 


Рассмотрим все соответствующие термины. 


Ошибка (еггог309, mistake) — действие человека, приводящее к некорректным резуль- 
татам. 


Этот термин очень часто используют как наиболее универсальный, описывающий любые 
проблемы («ошибка человека», «ошибка в коде», «ошибка в документации», «ошибка выполне- 
ния операции», «ошибка передачи данных», «ошибочный результат» и T. п.) Более того, куда чаще 
вы сможете услышать «отчёт об ошибке», чем «отчёт о дефекте». И это нормально, так сложилось 


исторически, к тому же термин «ошибка» на самом деле очень широкий. 


Дефект (defect310, bug, problem, fault) — недостаток в компоненте или системе, способ- 
НЫЙ привести K ситуации сбоя или отказа. 


Этот термин также понимают достаточно широко, говоря о дефектах в документации, на- 
стройках, входных данных и т.д. Почему глава называется именно «отчёты о дефектах»? Потому 
что этот термин как раз стоит посередине — бессмысленно писать отчёты о человеческих ошиб- 
ках, равно как и почти бесполезно просто описывать проявления сбоев и отказов — нужно доко- 


паться до их причины, и первым шагом в этом направлении является именно описание дефекта. 


309 Error, Mistake. А human action that produces ап incorrect result. [ISTQB Glossary] 

310 Defect, Bug, Problem, Fault. A flaw in a component or system that can cause the component or system to fail to 
perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may 
cause a failure of the component or system. [ISTQB Glossary] 


шиш 2.5. ОТЧЕТЫ 0 ДЕФЕКТАХ 169 


Сбой (interruption?!!) или отказ (failure312) — отклонение поведения системы от ожи- 
даемого. 


ВГОСТ 27.002-89 даны хорошие и краткие определения сбоя и отказа: 
Сбой — самоустраняющийся отказ или однократный отказ, устраняемый незначитель- 
ным вмешательством оператора. 


Отказ — событие, заключающееся в нарушении работоспособного состояния объекта. 


Эти термины скорее относятся к теории надёжности и нечасто встречаются в повседневной 
работе тестировщика, но именно сбои и отказы являются тем, что тестировщик замечает в про- 
цессе тестирования (и отталкиваясь от чего, проводит исследование с целью выявить дефект и 


его причины). 


Аномалия (апотау313) или инцидент (incident?!4, deviation) — любое отклонение Ha- 
блюдаемого (фактического) состояния, поведения, значения, результата, свойства от 


ожиданий наблюдателя, сформированных на основе требований, спецификаций, иной 


документации или опыта и здравого смысла. 


Итак, мы вернулись к тому, с чего начинали в части этой главы, описывающей предельно 
упрощённый взгляд на дефекты. Ошибки, дефекты, сбои, отказы и т.д. являются проявлением 
аномалий — отклонений фактического результата от ожидаемого. Стоит отметить, что ожидае- 
мый результат действительно может основываться на опыте и здравом смысле, т. к. поведение 
программного средства никогда не специфицируют до уровня базовых элементарных приёмов 
работы с компьютером. 

Теперь, чтобы окончательно избавиться от путаницы и двусмысленности, договоримся, что 
мы будем считать дефектом в контексте данной книги: 


Z Дефект — отклонение (deviation?!4) фактического результата (actual гези 315) от oxn- 
© даний наблюдателя (expected гези316), сформированных на основе требований, специ- 


фикаций, иной документации или опыта и здравого смысла. 


Отсюда логически вытекает, что дефекты могут встречаться не только в коде приложения, 
но и в любой документации, в архитектуре и дизайне, в настройках тестируемого приложения 
или тестового окружения — где угодно. 


311 Interruption. А suspension of а process, such аз the execution of a computer program, caused by ап event external to 
that process and performed in such a way that the process can be resumed. [http://www.electropedia.org/iev/iev.nsf/display? 
openform&ievref=714-22-10] 

312 Failure. Deviation of the component or system from its expected delivery, service or result. [ISTQB Glossary] 

313 Anomaly. Any condition that deviates from expectation based on requirements specifications, design documents, 
user documents, standards, etc. or from someone’s perception or experience. Anomalies may be found during, but not limited 
to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation. See also bug, defect, 
deviation, error, fault, failure, incident, problem. [ISTQB Glossary] 

314 Incident, Deviation. Any event occurring that requires investigation. [ISTQB Glossary] 

315 Actual result. The behavior produced/observed when a component or system is tested. [ISTQB Glossary] 

316 Expected result, Expected outcome, Predicted outcome. The behavior predicted by the specification, or another 
source, of the component or system under specified conditions. [ISTQB Glossary] 
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Важно понимать, что приведённое определение дефекта позволяет лишь поднять 
вопрос о том, является ли некое поведение приложения дефектом. В случае, если из 
проектной документации не следует однозначного положительного ответа, обязатель- 
но стоит обсудить свои выводы с коллегами и добиться донесения поднятого вопроса 
до заказчика, если его мнение по обсуждаемому «кандидату в баги» неизвестно. 
Хорошее представление о едва-едва затронутой нами теме теории надёжности можно 
получить, прочитав книгу Рудольфа Стапелберга «Руководство по надёжности, доступ- 
ности, ремонтопригодности и безопасности в инженерном проектировании» (Rudolph 
Frederick Stapelberg, «Handbook of Reliability, Availability, Maintainability and Safety in 
Engineering Design»). 


А краткую, но достаточно подробную классификацию аномалий в программных 
продуктах можно посмотреть в стандарте «IEEE 1044:2009 Standard Classification For 
Software Anomalies». 
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2.5.2. ОТЧЕТ 0 ДЕФЕКТЕ _ 
И ЕГО ЖИЗНЕННЫЙ ЦИКЛ шея 


Как было сказано в предыдущей главе, при обнаружении дефекта тестировщик создаёт отчёт 
о дефекте. 


ДЕЎ) Отчёт о дефекте (defect герогї?!7) — документ, описывающий и приоритизирующий 
обнаруженный дефект, а также содействующий его устранению. 


Как следует из самого определения, отчёт о дефекте пишется со следующими основными це- 
TAMI: 


• предоставить информацию о проблеме — уведомить проектную команду и иных заинтере- 
сованных лиц о наличии проблемы, описать суть проблемы; 

• приоритизировать проблему — определить степень опасности проблемы для проекта и же- 
лаемые сроки её устранения; 

e содействовать устранению проблемы — качественный отчёт о дефекте не только предостав- 
ляет все необходимые подробности для понимания сути случившегося, но также может со- 
держать анализ причин возникновения проблемы и рекомендации по исправлению ситуа- 
ЦИИ. 


На последней цели следует остановиться подробнее. Есть мнение, что «хорошо написанный 
отчёт о дефекте — половина решения проблемы для программиста». И действительно, как мы 
увидим далее (и особенно в главе «Типичные ошибки при написании отчётов о дефектах»{201), 
от полноты, корректности, аккуратности, подробности и логичности отчёта о дефекте зависит 
очень многое — одна и та же проблема может быть описана так, что программисту останется 
буквально исправить пару строк кода, а может быть описана и так, что сам автор отчёта на сле- 
дующий день не сможет понять, что же он имел в виду. 


= ВАЖНО! «Сверхцель» написания отчёта о дефекте состоит в быстром исправлении 
ошибки (а в идеале — и недопущении её возникновения в будущем). Потому качеству 
отчётов о дефекте следует уделять особое, повышенное внимание. 


Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цик- 
ла, которые схематично можно показать так (рисунок 2.5.с): 


e Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), 
в котором он находится сразу после создания. Некоторые средства также позволяют сначала 
создавать черновик (draft) и лишь потом публиковать отчёт. 

e Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто-то из проектной 
команды назначается ответственным за исправление дефекта. Назначение ответственного 
производится или решением лидера команды разработки, или коллегиально, или по добро- 
вольному принципу, или иным принятым в команде способом или выполняется автомати- 
чески на основе определённых правил. 


317 Defect report, Bug report. А document reporting оп any flaw їп а component ог system that сап cause ће component 
or system to fail to perform its required function. [ISTQB Glossary] 
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e Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефек- 


та член команды после выполнения соответствующих действий по исправлению. 


• Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившийся, 


что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестиров- 


щик, изначально написавший отчёт о дефекте. 


Обнаружен => Назначен => Исправлен Е Проверен 


М 


Открыт заново Закрыт 


у 
Рекомендован к 
— > 
отклонению 
у у 
Отложен До A Отклонён — 


Рисунок 2.5.c — Жизненный цикл отчёта о дефекте с наиболее типичными переходами 


между состояниями 


По поводу того, должен ли проверять факт устранения дефекта именно тот тестиров- 
щик, который его обнаружил, или обязательно другой, есть много «священных войн». 
Сторонники второго варианта утверждают, что свежий взгляд человека, ранее не зна- 
комого с данным дефектом, позволяет ему в процессе верификации с большой вероят- 
ностью обнаружить новые дефекты. 


Несмотря на то, что такая точка зрения имеет право на существование, всё же отме- 
тим: при грамотной организации процесса тестирования поиск дефектов эффективно 
происходит на соответствующей стадии работы, а верификация силами тестировщика, 
обнаружившего данный дефект, всё же позволяет существенно сэкономить время. 


Набор стадий жизненного цикла, их наименование и принцип перехода от стадии к 
стадии может различаться в разных инструментальных средствах управления жизнен- 
ным циклом отчётов о дефектах. Более того — многие такие средства позволяют гибко 
настраивать эти параметры. На рисунке 2.5.с показан лишь общий принцип. 


e Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется 


никаких дальнейших действий. Здесь есть некоторые расхождения в жизненном цикле, при- 


нятом в разных инструментальных средствах управления отчётами о дефектах: 
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° В некоторых средствах существуют оба состояния — «Проверен» и «Закрыт», чтобы 
подчеркнуть, что в состоянии «Проверен» ещё могут потребоваться какие-то допол- 
нительные действия (обсуждения, дополнительные проверки в новых билдах и т.д.), 
в то время как состояние «Закрыт» означает «с дефектом покончено, больше к этому 
вопросу не возвращаемся». 

° В некоторых средствах одного из состояний нет (оно поглощается другим). 

° В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте может 
быть переведён из множества предшествующих состояний с резолюциями наподобие: 


a «Не является дефектом» — приложение так и должно работать, описанное поведе- 
ние не является аномальным. 

" «Дубликат» — данный дефект уже описан в другом отчёте. 

a «Не удалось воспроизвести» — разработчикам не удалось воспроизвести пробле- 
му на своём оборудовании. 

= «Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его 
решено не исправлять. 

= «Невозможно исправить» — непреодолимая причина дефекта находится вне об- 
ласти полномочий команды разработчиков, например существует проблема в 
операционной системе или аппаратном обеспечении, влияние которой устранить 
разумными способами невозможно. 


Как было только что подчёркнуто, в некоторых средствах отчёт о дефекте в подоб- 
ных случаях будет переведён в состояние «Закрыт», в некоторых — в состояние 
«Отклонён», в некоторых — часть случаев закреплена за состоянием «Закрыт», часть — 
за «Отклонён». 

e Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт 
переводит тестировщик, удостоверившийся, что дефект по-прежнему воспроизводится на 
билде, в котором он уже должен быть исправлен. 

e Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть 
переведён из множества других состояний с целью вынести на рассмотрение вопрос об от- 
клонении отчёта по той или иной причине. Если рекомендация является обоснованной, от- 
чёт переводится в состояние «Отклонён» (см. следующий пункт). 

e Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных 
в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использо- 
вание этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту. 

e Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта 
в ближайшее время является нерациональным или не представляется возможным, одна- 
ко есть основания полагать, что в обозримом будущем ситуация исправится (выйдет новая 
версия библиотеки, вернётся из отпуска специалист по некоей технологии, изменятся тре- 


бования заказчика и т.д.) 


Для полноты рассмотрения данной подтемы приведём пример жизненного цикла, принято- 
го по умолчанию в инструментальном средстве управления отчётами о дефектах ЈІКАЗ!8 (рису- 
нок 2.5.4). 


318 «What is Workflow». [https://confluence.atlassian.com/display/JIRA/What+is+Workflow] 
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Рисунок 2.5.4 — Жизненный цикл отчёта о дефекте в ЛКА 


шиши 2.5. ОТЧЕТЫ 0 ДЕФЕКТАХ 175 


2.5.3. АТРИБУТЫ (ПОЛЯ) 
ОТЧЁТА O ДЕФЕКТЕ mamm 


В зависимости от инструментального средства управления отчётами о дефектах внешний вид 
их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но 
концепция остаётся неизменной. 

Общий вид всей структуры отчёта о дефекте представлен на рисунке 2.5.е. 


Идентификатор Шаги по воспроизведению 


Подробное описание 


Краткое описание 


19 | Бесконечный цикл об- | Если у входного файла выставлен |1. Поместить в каталог-ис- 
работки входного атрибут «только для чтения», по- точник файл допусти- 
файла с атрибутом сле обработки приложению не уда- мого типа и размера. 
«только для чтения» ётся переместить его в каталог- 2. Установить данному 

приёмник: создаётся копия файла, файлу атрибут «только 
но оригинал не удаляется, и при- для чтения». 
ложение снова и снова обрабаты- |3. Запустить приложение. 


вает этот файл и безуспешно пы- 
тается переместить его в каталог- 
приёмник. 

Ожидаемый результат: после об- 
работки файл перемещён из ката- 
лога-источника в каталог-приём- 


Дефект: обработанный 
файл появляется в ка- 
талоге-приёмнике, но 
не удаляется из ката- 
лога-источника, файл B 
каталоге-приёмнике 


ЗИК В непрерывно обновля- 
Фактический результат: обрабо- ется (видно по значе- 
танный файл копируется в ката- нию времени послед- 
лог-приёмник, но его оригинал него изменения). 


остаётся в каталоге-источнике. 
Требование: ДС-2.1. 


УМА УИ 


Воспроизводимость Возможность обойти 
Приложения 
Важнббть Срочность Комментарий 
> Всегда Средняя Обычная Некорректная Нет | Если заказчик не планирует | - 
операция использовать установку ат- 


рибута «только для чтения» 
файлам в каталоге-источ- 
нике для достижения неких 
своих целей, можно просто 
снимать этот атрибут и спо- 
койно перемещать файл. 


Рисунок 2.5.е — Общий вид отчёта о дефекте 


Задание 2.5.а: как вы думаете, почему этот отчёт о дефекте можно по формальным 
признакам отклонить с резолюцией «не является дефектом»? 
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Теперь рассмотрим каждый атрибут подробно. 


Идентификатор (identifier) представляет собой уникальное значение, позволяющее однознач- 
но отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем 
случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, 
но (если позволяет инструментальное средство управления отчётами) может быть и куда слож- 
нее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро 
определить суть дефекта и часть приложения (или требований), к которой он относится. 


Краткое описание (summary) должно в предельно лаконичной форме давать исчерпывающий 
ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произо- 
шло?». Например: «Отсутствует логотип на странице приветствия, если пользователь является 
администратором»: 


• Что произошло? Отсутствует логотип. 
» Где это произошло? На странице приветствия. 
• При каких условиях это произошло? Если пользователь является администратором. 


Одной из самых больших проблем для начинающих тестировщиков является именно заполне- 
ние поля «краткое описание», которое одновременно должно: 


• содержать предельно краткую, но в то же время достаточную для понимания сути проблемы 
информацию о дефекте; 

e отвечать на только что упомянутые вопросы («что, где и при каких условиях случилось») 
или как минимум на те 1-2 вопроса, которые применимы к конкретной ситуации; 

e быть достаточно коротким, чтобы полностью помещаться на экране (в тех системах управ- 
ления отчётами о дефектах, где конец этого поля обрезается или приводит к появлению 
скроллинга); 

• при необходимости содержать информацию об окружении, под которым был обнаружен 
дефект; 

• по возможности не дублировать краткие описания других дефектов (и даже не быть похо- 
жими на них), чтобы дефекты было сложно перепутать или посчитать дубликатами друг 
пруга; 

e быть законченным предложением русского или английского (или иного) языка, построен- 
ным по соответствующим правилам грамматики. 


Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим 
алгоритмом: 


1. Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого, кристаль- 
но чистого понимания того, «что сломалось», писать отчёт о дефекте вообще едва ли стоит. 

2. Сформулировать подробное описание (description) дефекта — сначала без оглядки на длину 
получившегося текста. 

3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали. 

4. Выделить в подробном описании слова (словосочетания, фрагменты фраз), отвечающие на 
вопросы, «что, где и при каких условиях случилось». 

5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного пред- 
ложения. 

6. Если предложение получилось слишком длинным, переформулировать его, сократив дли- 
ну (за счёт подбора синонимов, использования общепринятых аббревиатур и сокращений). 
К слову, в английском языке предложение почти всегда будет короче русского аналога. 


Рассмотрим несколько примеров применения этого алгоритма. 


Ситуация 1. Тестированию подвергается некое веб-приложение, поле описания товара долж- 
но допускать ввод максимум 250 символов; в процессе тестирования оказалось, что этого огра- 
ничения нет. 
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1. Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет 
никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О то- 
варе» данных. 

2. Исходный вариант подробного описания: в клиентской и серверной части приложения от- 
сутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице 
http://testapplication/admin/goods/edit/. 

3. Конечный вариант подробного описания: 


• Фактический результат: в описании товара (поле «О товаре», http://testapplication/admin/ 
goods/edit/) отсутствуют проверка и ограничение длины вводимого текста (МАХ= 
250 символов). 

e Ожидаемый результат: в случае попытки ввода 251+ символов выводится сообщение 
об ошибке. 


4. Определение «что, где и при каких условиях случилось»: 


• Что: отсутствуют проверка и ограничение длины вводимого текста. 
• Где: описание товара, поле «О товаре», http://testapplication/admin/goods/edit/. 


5. При каких условиях: - (в данном случае дефект присутствует всегда, вне зависимости от 
каких бы то ни было особых условий). 

6. Первичная формулировка: отсутствуют проверка и ограничение максимальной длины 
текста, вводимого в поле «О товаре» описания товара. 

7. Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля 
«О товаре». Английский вариант: по check for «О товаре» max length. 


Ситуация 2. Попытка открыть в приложении пустой файл приводит к краху клиентской части 
приложения и потере несохранённых пользовательских данных на сервере. 


1. Суть проблемы: клиентская часть приложения начинает «вслепую» читать заголовок фай- 
ла, не проверяя ни размер, ни корректность формата, ничего; возникает некая внутренняя 
ошибка, и клиентская часть приложения некорректно прекращает работу, не закрыв сессию 
с сервером; сервер закрывает сессию по таймауту (повторный запуск клиентской части за- 
пускает новую сессию, так что старая сессия и все данные в ней в любом случае утеряны). 

2. Исходный вариант подробного описания: некорректный анализ открываемого клиентом 
файла приводит к краху клиента и необратимой утере текущей сессии с сервером. 

3. Конечный вариант подробного описания: 


e Фактический результат: отсутствие проверки корректности открываемого клиентской 
частью приложения файла (в том числе пустого) приводит к краху клиентской части и 
необратимой потере текущей сессии с сервером (см. ВВ852345). 

e Ожидаемый результат: производится анализ структуры открываемого файла; в случае 
обнаружения проблем отображается сообщение о невозможности открытия файла. 


4. Определение «что, где и при каких условиях случилось»: 


e Что: крах клиентской части приложения. 
• Ще: - (конкретное место в приложении определить едва ли возможно). 
• При каких условиях: при открытии пустого или повреждённого файла. 


5. Первичная формулировка: отсутствие проверки корректности открываемого файла приво- 
дит к краху клиентской части приложения и потере пользовательских данных. 

6. Сокращение (итоговое краткое описание): крах клиента и потеря данных при открытии по- 
вреждённых файлов. Английский вариант: client crash and data loss оп damaged/empty files 
opening. 
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Ситуация 3. Крайне редко по совершенно непонятным причинам на сайте нарушается ото- 


бражение всего русского текста (как статических надписей, так и данных из базы данных, гене- 


рируемых динамически и т.д. — всё «становится вопросиками»). 


1. 


Суть проблемы: фреймворк, на котором построен сайт, подгружает специфические шрифты 
с удалённого сервера; если соединение обрывается, нужные шрифты не подгружаются, и 
используются шрифты по умолчанию, в которых нет русских символов. 


. Исходный вариант подробного описания: ошибка загрузки шрифтов с удалённого сервера 


приводит к использованию локальных несовместимых с требуемой кодировкой шрифтов. 


. Конечный вариант подробного описания: 


• Фактический результат: периодическая невозможность загрузить шрифты с удалённо- 
го сервера приводит к использованию локальных шрифтов, несовместимых с требуе- 
мой кодировкой. 

e Ожидаемый результат: необходимые шрифты подгружаются всегда (или используется 
локальный источник необходимых шрифтов). 


. Определение «что, где и при каких условиях случилось»: 


• Что: используются несовместимые с требуемой кодировкой шрифты. 

• Ще: – (по всему сайту). 

• При каких условиях: в случае ошибки соединения с сервером, с которого подгружаются 
шрифты. 


. Первичная формулировка: периодические сбои внешнего источника шрифтов приводят к 


сбою отображения русского текста. 


. Сокращение (итоговое краткое описание): неверный показ русского текста при недоступ- 


ности внешних шрифтов. Английский вариант: wrong presentation of Russian text in case of 


external fonts inaccessibility. 


Для закрепления материала ещё раз представим эти три ситуации в виде таблицы 2.5.а. 


Таблица 2.5.а — Проблемные ситуации и формулировки кратких описаний дефектов 


Ситуация 


Русский вариант 
краткого описания 


Английский вариант 
краткого описания 


Тестированию подвергается некое веб-прило- 
жение, поле описания товара должно допускать 
ввод максимум 250 символов; в процессе тести- 
рования оказалось, что этого ограничения нет. 


Нет ограничения 
максимальной длины 
поля «О товаре». 


No check Юг 
«О товаре» 
max length. 


Попытка открыть в приложении пустой файл 
приводит к краху клиентской части приложе- 
ния и потере несохранённых пользовательских 
данных на сервере. 


Крах клиента и 
потеря данных при 
открытии повреждён- 
ных файлов. 


Client crash and data 
loss on damaged/empty 
files opening. 


Крайне редко по совершенно непонятным при- 
чинам на сайте нарушается отображение все- 
го русского текста (как статических надписей, 
так и данных из базы данных, генерируемых 
динамически и т. д. — всё «становится вопроси- 
ками»). 


Неверный показ 
русского текста при 
недоступности внеш- 
них шрифтов. 


Wrong presentation 
of Russian text in 
case of external fonts 
inaccessibility. 


Возвращаемся к рассмотрению полей отчёта о дефекте. 
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Подробное описание (description) представляет в развёрнутом виде необходимую информа- 
цию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результа- 
та и ссылку на требование (если это возможно). 


Пример подробного описания: 


Если в систему входит администратор, на странице приветствия отсутствует логотип. 
Фактический результат: логотип отсутствует в левом верхнем углу страницы. 
Ожидаемый результат: логотип отображается в левом верхнем углу страницы. 
Требование: В245.3.23Ъ. 


В отличие от краткого описания, которое, как правило, является одним предложением, здесь 
можно и нужно давать подробную информацию. Если одна и та же проблема (вызванная одним 
источником) проявляется в нескольких местах приложения, можно в подробном описании пе- 
речислить эти места. 


Шаги по воспроизведению (steps to reproduce, STR) описывают действия, которые необходи- 
мо выполнить для воспроизведения дефекта. Это поле похоже на шаги тест-кейса, за исключени- 
ем одного важного отличия: здесь действия прописываются максимально подробно, суказанием 
конкретных вводимых значений и самых мелких деталей, т.к. отсутствие ЭТОЙ информации В 
сложных случаях может привести к невозможности воспроизведения дефекта. 


Пример шагов воспроизведения: 


1. Открыть http://testapplication/admin/login/. 
2. Авторизоваться с именем «defaultadmin» и паролем «dapassword». 


Дефект: в левом верхнем углу страницы отсутствует логотип (вместо него отображается 
пустое пространство с надписью «logo»). 


Воспроизводимость (reproducibility) показывает, при каждом ли прохождении по шагам BOC- 
произведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: 
всегда (always) или иногда (sometimes). 

Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоя- 
щую причину возникновения дефекта. Это приводит к серьёзным дополнительным сложностям 
в работе с дефектом: 


e Тестировщику нужно потратить много времени на то, чтобы удостовериться в наличии 
дефекта (т.к. однократный сбой в работе приложения мог быть вызван огромным количе- 
ством посторонних причин). 

e Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедить- 
ся в его наличии. После внесения исправлений в приложение разработчик фактически дол- 
жен полагаться только на свой профессионализм, т.к. даже многократное прохождение по 
шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возмож- 
но, через ещё 10-20 повторений он бы проявился). 

e Тестировщику, верифицирующему исправление дефекта и вовсе остаётся верить разработ- 
чику на слово по той же самой причине: даже если он попытается воспроизвести дефект 
100 раз и потом прекратит попытки, может так случиться, что на 101-й раз дефект всё же 
воспроизвёлся бы. 
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Как легко догадаться, такая ситуация является крайне неприятной, а потому рекомендуется 
один раз потратить время на тщательную диагностику проблемы, найти её причину и перевести 
дефект в разряд воспроизводимых всегда. 


Важность (severity) показывает степень ущерба, который наносится проекту существованием 
дефекта. 
В общем случае выделяют следующие градации важности: 


e Критическая (critical) — существование дефекта приводит к масштабным последствиям Ka- 
тастрофического характера, например: потеря данных, раскрытие конфиденциальной ин- 
формации, нарушение ключевой функциональности приложения ит.д. 

e Высокая (major) — существование дефекта приносит ощутимые неудобства многим пользо- 
вателям в рамках их типичной деятельности, например: недоступность вставки из буфера 
обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость 
перезапуска приложения при выполнении типичных сценариев работы. 

• Средняя (medium) — существование дефекта слабо влияет на типичные сценарии работы 
пользователей, и/или существует обходной путь достижения цели, например: диалоговое 
окно не закрывается автоматически после нажатия кнопок «ОК»/«Сапсе, при распечатке 
нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», пере- 
путаны направления сортировок по некоему полю таблицы. 

e Низкая (minor) — существование дефекта редко обнаруживается незначительным процен- 
том пользователей и (почти) не влияет на их работу, например: опечатка в глубоко вложен- 
ном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нуж- 
но перетянуть его в удобное место), неточно отображается время до завершения операции 
копирования файлов. 


Срочность (priority) показывает, как быстро дефект должен быть устранён. 
В общем случае выделяют следующие градации срочности: 


e Наивысшая (ASAP, аз soon аз possible) срочность указывает на необходимость устранить 
дефект настолько быстро, насколько это возможно. В зависимости от контекста «настоль- 
ко быстро, насколько возможно» может варьироваться от «в ближайшем билде» до единиц 
минут. 

• Высокая (high) срочность означает, что дефект следует исправить вне очереди, т.к. его суще- 
ствование или уже объективно мешает работе, или начнёт создавать такие помехи в самом 
ближайшем будущем. 

• Обычная (normal) срочность означает, что дефект следует исправить в порядке общей oye- 
рёдности. Такое значение срочности получает большинство дефектов. 

e Низкая (low) срочность означает, что в обозримом будущем исправление данного дефекта 
не окажет существенного влияния на повышение качества продукта. 


Несколько дополнительных рассуждений о важности и срочности стоит рассмотреть от- 
дельно. 

Один из самых частых вопросов относится к тому, какая между ними связь. Никакой. Для луч- 
шего понимания этого факта можно сравнить важность и срочность с координатами Хиу точки 
на плоскости. Хоть «на бытовом уровне» и кажется, что дефект с высокой важностью следует 
исправить в первую очередь, в реальности ситуация может выглядеть совсем иначе. 

Чтобы проиллюстрировать эту мысль подробнее, вернёмся к перечню градаций: заметили ли 
вы, что для разных степеней важности примеры приведены, а для разных степеней срочности — 
нет? И это не случайно. 

Зная суть проекта и суть дефекта, его важность определить достаточно легко, т.к. мы можем 
проследить влияние дефекта на критерии качества, степень выполнения требований той или 
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иной важности и Т.Д. Но срочность исправления дефекта можно определить только в конкрет- 


ной ситуации. 


Поясним на жизненном примере: насколько для жизни человека важна вода? Очень важна, 
без воды человек умирает. Значит, важность воды для человека можно оценить как критическую. 
Но можем ли мы ответить на вопрос «Как быстро человеку нужно выпить воды?», не зная, о 


какой ситуации идёт речь? Если рассматриваемый человек умирает от жажды в пустыне, сроч- 
ность будет наивысшей. Если он просто сидит в офисе и думает, не попить ли чая, срочность 
будет обычной или даже низкой. 

Вернёмся к примерам из разработки программного обеспечения и покажем четыре случая со- 
четания важности и срочности в таблице 2.5.Ъ. 


Таблииа 2.5.6 — Примеры сочетания важности и срочности дефектов 


Важность 


Критическая 
Проблемы с безопасностью во 


Низкая 
На корпоративном сайте повре- 


ны или вовсе утеряны пользова- 


Наивысшая |введённом в эксплуатацию бан-|дилась картинка с фирменным 
ковском ПО. логотипом. 
В самом начале разработки про- 
Срочность 
екта обнаружена ситуация, при | В руководстве пользователя об- 
Низкая которой могут быть поврежде- | наружено несколько опечаток, 


не влияющих на смысл текста. 


тельские данные. 


Симптом (symptom) — позволяет классифицировать дефекты по их типичному проявлению. 
Не существует никакого общепринятого списка симптомов. Более того, далеко не в каждом ин- 
струментальном средстве управления отчётами о дефектах есть такое поле, а там, где оно есть, 
его можно настроить. В качестве примера рассмотрим следующие значения симптомов дефекта. 


Косметический дефект (cosmetic flaw) — визуально заметный недостаток интерфейса, не 
влияющий на функциональность приложения (например, надпись на кнопке выполнена 
шрифтом не той гарнитуры). 

Повреждение/потеря данных (data соггирНоп/1055) — в результате возникновения дефекта 
искажаются, уничтожаются (или не сохраняются) некоторые данные (например, при копи- 
ровании файлов копии оказываются повреждёнными). 

Проблема в документации (documentation issue) — дефект относится не к приложению, 
а к документации (например, отсутствует раздел руководства по эксплуатации). 
Некорректная операция (incorrect operation) — некоторая операция выполняется некор- 
ректно (например, калькулятор показывает ответ 17 при умножении 2 на 3). 

Проблема инсталляции (installation problem) — дефект проявляется на стадии установки 
и/или конфигурирования приложения (см. инсталляционное тестирование{88}). 

Ошибка локализации (localization issue) — что-то в приложении не переведено или переве- 
дено неверно на выбранный язык интерфейса (см. локализационное тестирование 1). 
Нереализованная функциональность (missing feature) — некая функция приложения не вы- 
полняется или не может быть вызвана (например, в списке форматов для экспорта докумен- 
та отсутствует несколько пунктов, которые там должны быть). 

Проблема масштабируемости (scalability) — при увеличении количества доступных при- 
ложению ресурсов не происходит ожидаемого прироста производительности приложения 
(см. тестирование производительности 3} и тестирование масштабируемости 4}. 

Низкая производительность (low performance) — выполнение неких операций занимает He- 
допустимо большое время (см. тестирование производительности 3}). 
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e Крах системы (system crash) — приложение прекращает работу или теряет способность вы- 
полнять свои ключевые функции (также может сопровождаться крахом операционной си- 
стемы, веб-сервера и т.д.). 

• Неожиданное поведение (unexpected behavior) — в процессе выполнения некоторой типич- 
ной операции приложение ведёт себя необычным (отличным от общепринятого) образом 
(например, после добавления в список новой записи активной становится не новая запись, 
а первая в списке). 

• Недружественное поведение (unfriendly behavior) — поведение приложения создаёт поль- 
зователю неудобства в работе (например, на разных диалоговых окнах в разном порядке 
расположены кнопки «ОК» и «Сапсе]»). 

e Расхождение с требованиями (variance from specs) — этот симптом указывают, если дефект 
сложно соотнести с другими симптомами, но тем не менее приложение ведёт себя не так, как 
описано в требованиях. 

• Предложение по улучшению (enhancement) — во многих инструментальных средствах 
управления отчётами о дефектах для этого случая есть отдельный вид отчёта, т.к. предло- 
жение по улучшению формально нельзя считать дефектом: приложение ведёт себя согласно 
требованиям, но у тестировщика есть обоснованное мнение о том, как ту или иную функ- 
циональность можно улучшить. 


Часто встречается вопрос о том, может ли у одного дефекта быть сразу несколько симпто- 
мов. Да, может. Например, крах системы очень часто ведёт к потере или повреждению данных. 
Но В большинстве инструментальных средств управления отчётами о дефектах значение поля 
«Симптом» выбирается из списка, и потому нет возможности указать дваи более симптома од- 
ного дефекта. В такой ситуации рекомендуется выбирать либо симптом, который лучше всего 
описывает суть ситуации, либо «наиболее опасный» симптом (например, недружественное по- 
ведение, состоящее в том, что приложение не запрашивает подтверждения перезаписи сущест- 
вующего файла, приводит к потере данных; здесь «потеря данных» куда уместнее, чем «недру- 
жественное поведение»). 


Возможность обойти (workaround) — показывает, существует ли альтернативная последо- 
вательность действий, выполнение которой позволило бы пользователю достичь поставленной 
цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, 
выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управле- 
ния отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых 
при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что 
дефектам без возможности обхода стоит повысить срочность исправления. 


Комментарий (comments, additional info) — может содержать любые полезные для понимания 
и исправления дефекта данные. Иными словами, сюда можно писать всё то, что нельзя писать в 
остальные поля. 


Приложения (attachments) — представляет собой не столько поле, сколько список прикреп- 
лённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.) 
Общие рекомендации по формированию приложений таковы: 


• Если вы сомневаетесь, делать или не делать приложение, лучше сделайте. 

e Обязательно прилагайте т.н. «проблемные артефакты» (например, файлы, которые прило- 
жение обрабатывает некорректно). 

• Если вы прилагаете копию экрана: 


° Чаще всего вам будет нужна копия активного окна (Alt+PrintScreen), а не всего экрана 
(PrintScreen). 

° Обрежьте всё лишнее (используйте Snipping Tool или Paint в Windows, Pinta или XPaint 
B Linux). 
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° Отметьте на копии экрана проблемные места (обведите, нарисуйте стрелку, добавьте 
надпись — сделайте всё необходимое, чтобы с первого взгляда проблема была заметна 
и понятна). 

° В некоторых случаях стоит сделать одно большое изображение из нескольких ко- 
пий экрана (разместив их последовательно), чтобы показать процесс воспроизве- 
дения дефекта. Альтернативой этого решения является создание нескольких копий 
экрана, названных так, чтобы имена образовывали последовательность, например: 
br_9_sc_01.png, br_9_sc_02.png, br_9_sc_03.png. 

° Сохраните копию экрана в формате JPG (если важна экономия объёма данных) или 
PNG (если важна точная передача картинки без искажений). 


• Если вы прилагаете видеоролик с записью происходящего на экране, обязательно оставляй- 
те только тот фрагмент, который относится к описываемому дефекту (это будет буквально 
несколько секунд или минут из возможных многих часов записи). Старайтесь подобрать 
настройки кодеков так, чтобы получить минимальный размер ролика при сохранении до- 
статочного качества изображения. 

° Поэкспериментируйте с различными инструментами создания копий экрана и записи ви- 
деороликов с происходящим на экране. Выберите наиболее удобное для вас программное 
обеспечение и приучите себя постоянно его использовать. 


Для более глубокого понимания принципов оформления отчётов о дефектах рекомендуется 
прямо сейчас ознакомиться с главой «Типичные ошибки при написании отчётов о дефектах» {201}, 
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= Так называемые «инструментальные средства управления отчётами о дефектах» в 
@ обычной разговорной речи называют «баг-трекинговыми системами», «баг-трекера- 
ми» и т.д. Но мы здесь по традиции будем придерживаться более строгой термино- 


логии. 


Инструментальных средств управления отчётами о дефектах (bug tracking system, defect 
management 001319) очень много?20, к тому же многие компании разрабатывают свои внутрен- 
ние средства решения этой задачи. Зачастую такие инструментальные средства являются частя- 
ми инструментальных средств управления тестированием(!32). 

Как и в случае с инструментальными средствами управления тестированием, здесь не имеет 
смысла заучивать, как работать с отчётами о дефектах в том или ином средстве. Мы лишь рас- 


смотрим общий набор функций, как правило, реализуемых такими средствами: 


• Создание отчётов о дефектах, управление их жизненным циклом с учётом контроля версий, 
прав доступа и разрешённых переходов из состояния в состояние. 

• Сбор, анализ и предоставление статистики в удобной для восприятия человеком форме. 

• Рассылка уведомлений, напоминаний и иных артефактов соответствующим сотрудникам. 

• Организация взаимосвязей между отчётами о дефектах, тест-кейсами, требованиями и ана- 
лиз таких связей с возможностью формирования рекомендаций. 

• Подготовка информации для включения в отчёт о результатах тестирования. 


° Интеграция с системами управления проектами. 


Иными словами, хорошее инструментальное средство управления жизненным циклом отчё- 
тов о дефектах не только избавляет человека от необходимости внимательно выполнять большое 
количество рутинных операций, нои предоставляет дополнительные возможности, облегчаю- 
щие работу тестировщика и делающие её более эффективной. 


Для общего развития и лучшего закрепления темы об оформлении отчётов о дефектах мы сей- 
час рассмотрим несколько картинок с формами из разных инструментальных средств. 

Здесь вполне сознательно не приведено никакого сравнения или подробного описания — по- 
добных обзоров достаточно в Интернете, и они стремительно устаревают по мере выхода новых 
версий обозреваемых продуктов. 

Но интерес представляют отдельные особенности интерфейса, на которые мы обратим вни- 
мание в каждом из примеров (важно: если вас интересует подробное описание каждого поля, 
связанных с ним процессов и т.д., обратитесь к официальной документации — здесь будут лишь 
самые краткие пояснения). 


319 Defect management tool, Incident management tool. А tool that facilitates ће recording апа status tracking of defects 
and changes. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of defects 
and provide reporting facilities. See also incident management tool. [ISTQB Glossary] 

320 «Comparison of issue-tracking systems», Wikipedia [http://en.wikipedia.org/wiki/Comparison_of_issue-tracking 
systems] 
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11. 


12. 
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14. 


Project (проект) позволяет указать, к какому проекту относится дефект. 

Issue type (тип записи/артефакта) позволяет указать, что именно представляет собой созда- 
ваемый артефакт. JIRA позволяет создавать не только отчёты о дефектах, но и множество 
других артефактов?22, типы которых можно настраивать?23. По умолчанию представлены: 


• Improvement (предложение по улучшению) — было описано подробно в разделе, посвя- 
щённом полям отчёта о дефекте (см. описание поля «симптом», значение «предложение 
по улучшению» 182). 

e New feature (новая особенность) — описание новой функциональности, нового свой- 
ства, новой особенности продукта. 

e Task (задание) — некое задание для выполнения тем или иным участником проектной 
команды. 

e Custom issue (произвольный артефакт) — как правило, это значение при настройке 
JIRA удаляют, заменяя своими вариантами, или переименовывают в Issue. 


Summary (краткое описание) позволяет указать краткое описание дефекта. 
Priority (срочность) позволяет указать срочность исправления дефекта. По умолчанию 
ЛКА предлагает следующие варианты: 


e Highest (самая высокая срочность). 
e High (высокая срочность). 

e Medium (обычная срочность). 

e Low (низкая срочность). 

e Lowest (самая низкая срочность). 


Обратите внимание: по умолчанию поля severity (важность) нет. Но его можно добавить. 


Components (компоненты) содержит перечень компонентов приложения, затронутых де- 
фектом (хотя иногда здесь перечисляют симптомы дефектов). 


Affected versions (затронутые версии) содержит перечень версий продукта, в которых про- 
является дефект. 


Environment (окружение) содержит описание аппаратной и программной конфигурации, 
в которой проявляется дефект. 


Description (подробное описание) позволяет указать подробное описание дефекта. 


Original estimate (начальная оценка времени исправления) позволяет указать начальную 
оценку того, сколько времени займёт устранение дефекта. 


Remaining estimate (расчётное остаточное время исправления) показывает, сколько време- 
ни осталось от начальной оценки. 


Story points (оценочные единицы) позволяет указать сложность дефекта (или иного арте- 
факта) в специальных оценочных единицах, принятых в гибких методологиях управления 
проектами. 


Labels (метки) содержит метки (теги, ключевые слова), по которым можно группировать и 
классифицировать дефекты и иные артефакты. 


Ерїс/Тһете (история/область) содержит перечень высокоуровневых меток, описывающих 
относящиеся к дефекту крупные области требований, крупные модули приложения, круп- 
ные части предметной области, объёмные пользовательские истории ит.д. 

External issue id (идентификатор внешнего артефакта) позволяет связать отчёт о дефекте 
или иной артефакт с внешним документом. 
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Create Issue 38: Configure Fields ~ 
Project = 
Issue Туре’ (ж) Вид - © 
> ‚ 


Priority + Major -|© 


omponent/s 


Start typing to get a list of possible matches or press down to select 
Affects Version/s 


Start typing to get a list of possible matches or press down to select 


Environment Z 


For example operating sy stem, software platform and/or hardware specifications (include as appropriate for 
the issue). 


Description S) 


19) 


Óriginal Esma (ед. Зм 4d 12h) ©) 


The original estimate оѓ how much work is involved іп геѕоміпо this issue. 


Remaining = (eg. Зм 4d 12h) © 
An estimate of how much work remains until this issue will be resolved. 
Story Points 


Measurement of complexity and/or size of a requirement. 
Labels z 
Begin typing to find and create labels or press down to select a suggested label. 
Еріс/Тћете 


Begin typing to find апа create labels or press down to select а suggested label 


Field that will help you regroup issues under an Epic or under a theme 


External issue ID 


External issue ID 
Epic Link z 
Choose an epic to assign this issue to. 


Has a Story/s 


Link/s to Story issue type 


Tester 2а 
Start typing їо get а list of possible matches. 
Additional 
information 


Sprint None 
JIRA Agile sprint field 


El create another Cancel 


Рисунок 2.5.f — Создание отчёта о дефекте в JIRA 
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15. 


16. 


17. 
18. 


19. 


Epic link (ссылка на историю/область) содержит ссылку на историю/область (см. пункт 13), 
наиболее близко относящуюся к дефекту. 

Has а story/s (истории) содержит ссылки и/или описание пользовательских историй, CBA- 
занных с дефектом (как правило, здесь приводятся ссылки на внешние документы). 

Тезїег (тестировщик) содержит имя автора описания дефекта. 

Additional information (дополнительная информация) содержит полезную дополнительную 
информацию о дефекте. 

Sprint (спринт) содержит номер спринта (2-4-недельной итерации разработки проекта в 
терминологии гибких методологий управления проектами), во время которого был обна- 
ружен дефект. 


Многие дополнительные поля и возможности становятся доступными при других операциях 
с дефектами (просмотром или редактированием созданного дефекта, просмотре отчётов и т. д.) 


Bugzilla324 


1. 
2. 
3. 


10. 


Ргодисї (продукт) позволяет указать, к какому продукту (проекту) относится дефект. 
Reporter (автор отчёта) содержит e-mail автора описания дефекта. 

Component (компонент) содержит указание компонента приложения, к которому относит- 
ся описываемый дефект. 

Component description (описание компонента) содержит описание компонента приложе- 
ния, к которому относится описываемый дефект. Эта информация загружается автомати- 
чески при выборе компонента. 

Version (версия) содержит указание версии продукта, в которой был обнаружен дефект. 
Severity (важность) содержит указание важности дефекта. По умолчанию предложены Ta- 
кие варианты: 


e Blocker (блокирующий дефект) — дефект не позволяет решить с помощью приложения 
некоторую задачу. 

e Critical (критическая важность). 

e Major (высокая важность). 

• Normal (обычная важность). 

• Міпог (низкая важность). 

e Trivial (самая низкая важность). 

e Enhancement (предложение по улучшению) — было описано подробно в разделе, посвя- 
щённом полям отчёта о дефекте (см. описание поля «симптом», значение «предложение 
по улучшению» 82}. 


Hardware (аппаратное обеспечение) позволяет выбрать профиль аппаратного окружения, 
в котором проявляется дефект. 

OS (операционная система) позволяет указать операционную систему, под которой прояв- 
ляется дефект. 

Priority (срочность) позволяет указать срочность исправления дефекта. По умолчанию 
Bugzilla предлагает следующие варианты: 


e Highest (самая высокая срочность). 
e High (высокая срочность). 

e Normal (обычная срочность). 

e Low (низкая срочность). 

e Lowest (самая низкая срочность). 


Status (статус) позволяет установить статус отчёта о дефекте. По умолчанию Bugzilla пред- 
лагает следующие варианты статусов: 


324 «Bugzilla» [https://www.bugzilla.org] 
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* Product: TestProduct Reporter: user@user.com A 2 


* Component: ВРЕТ · Component Description 
This is а test component. 


| ИР 


* Version: ИШИ. Severity: enhancement ~ 
Hardware: PC м 
- 05: Windows ~ — в) 
Priority: --- ы 
Status: CONFIRMED М О 


Assignee: адт@адт.сот 


сс: 
Default СС: 
Orig. Est.: Хт) 


Deadline: 


о 


Alias: 


URL: http:// 


* Summary: | 


Description: 


Attachment: [ Add ап attachment Eo) 


Depends оп: 


Blocks: 


[ Submit Bug ) l Remember values as bookmarkable template ) 


Рисунок 2.5.9 — Создание отчёта о дефекте в Bugzilla 
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11. 


12. 


13. 


14. 


15. 


16. 


17. 
18. 
19. 
20. 
21. 


22. 


e Unconfirmed (не подтверждено) — дефект пока не изучен, и нет гарантии того, что он 
действительно корректно описан. 

• Confirmed (подтверждено) — дефект изучен, корректность описания подтверждена. 

• In progress (в работе) — ведётся работа по изучению и устранению дефекта. 


В официальной документации рекомендуется сразу же после установки Bugzilla сконфигу- 
рировать набор статусов и правила жизненного цикла отчёта о дефектах в соответствии с 
принятыми в вашей компании правилами. 


Assignee (ответственный) указывает e-Mail участника проектной команды, ответственного 
за изучение и исправление дефекта. 

СС (уведомлять) содержит список e-mail адресов участников проектной команды, которые 
будут получать уведомления о происходящем с данным дефектом. 

Default СС (уведомлять по умолчанию) содержит e-mail адрес(а) участников проектной KO- 
манды, которые по умолчанию будут получать уведомления о происходящем с любыми 
дефектами (чаще всего здесь указываются e-mail адреса рассылок). 

Original estimation (начальная оценка) позволяет указать начальную оценку того, сколько 
времени займёт устранение дефекта. 

Deadline (крайний срок) позволяет указать дату, к которой дефект обязательно нужно MC- 
править. 

Alias (псевдоним) позволяет указать короткое запоминающееся название дефекта (воз- 
можно, в виде некоей аббревиатуры) для удобства упоминания дефекта в разнообразных 
документах. 

URL (URL) позволяет указать URL, по которому проявляется дефект (особенно актуально 
для веб-приложений). 

Summary (краткое описание) позволяет указать краткое описание дефекта. 

Description (подробное описание) позволяет указать подробное описание дефекта. 
Attachment (вложение) позволяет добавить к отчёту о дефекте вложения в виде прикреп- 
лённых файлов. 

Depends оп (зависит от) позволяет указать перечень дефектов, которые должны быть 
устранены до начала работы с данным дефектом. 

Blocks (блокирует) позволяет указать перечень дефектов, к работе с которыми можно будет 
приступить только после устранения данного дефекта. 


Матіі$325 


1. 


Category (категория) содержит указание проекта или компонента приложения, к которому 
относится описываемый дефект. 

Reproducibility (воспроизводимость) дефекта. Mantis предлагает нетипично большое коли- 
чество вариантов: 

e Always (всегда). 

• Sometimes (иногда). 

e Random (случайным образом) — вариация на тему «иногда», когда не удалось устано- 
вить никакой закономерности проявления дефекта. 

e Have not tried (не проверено) — это не столько воспроизводимость, сколько статус, 
но Mantis относит это значение к данному полю. 

e Unable to reproduce (не удалось воспроизвести) — это не столько воспроизводимость, 
сколько резолюция к отклонению отчёта о дефекте, но в Mantis тоже отнесено к данно- 
му полю. 

e N/A (non-applicable, неприменимо) — используется для дефектов, к которым не приме- 
нимо понятие воспроизводимости (например, проблемы с документацией). 


325 «Mantis Bug Tracker» [https://www.mantisbt.org] 
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Enter Report Details 
*Category [All Projects] General ~ 


Reproducibility have not tried 
Severity minor ~ 
Priority normal 
Select Profile Or Fill In 


Platform 


os 
OS Version 


Product Version 
*Summary 


*Description 
Steps To Reproduce 


Additional Information 


Го 
A 
29 

© 


Upload File Browse.. | No file selected. 
Maximum size: 2,097 KB 


View Status @ public private 


Report Stay check to report more issues 


* required | Submit Report ] 


Рисунок 2.5.й — Создание отчёта о дефекте в Mantis 


3. Severity (важность) содержит указание важности дефекта. По умолчанию предложены та- 
кие варианты: 

e Block (блокирующий дефект) — дефект не позволяет решить с помощью приложения 
некоторую задачу. 

e Crash (критическая важность) — как правило, относится к дефектам, вызывающим не- 
работоспособность приложения. 

e Major (высокая важность). 

e Minor (низкая важность). 
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Tweak (доработка) — как правило, косметический дефект. 

Text (текст) — как правило, дефект относится к тексту (опечатки и т.д.). 

• Trivial (самая низкая важность). 

Feature (особенность) — отчёт представляет собой не описание дефекта, а запрос на 
добавление/изменение функциональности или свойств приложения. 


4. Priority (срочность) позволяет указать срочность исправления дефекта. По умолчанию 
Mantis предлагает следующие варианты: 


• Immediate (незамедлительно). 

e Urgent (самая высокая срочность). 

e High (высокая срочность). 

e Normal (обычная срочность). 

e Low (низкая срочность). 

e None (нет) — срочность не указана или не может быть определена. 


5. Select profile (выбрать профиль) позволяет выбрать из заранее подготовленного списка 
профиль аппаратно-программной конфигурации, под которой проявляется дефект. Если 
такого списка нет или он не содержит необходимых вариантов, можно вручную заполнить 
поля 6-7-8 (см. ниже). 

6. Platform (платформа) позволяет указать аппаратную платформу, под которой проявляется 
дефект. 

7. OS (операционная система) позволяет указать операционную систему, под которой прояв- 
ляется дефект. 

8. OS Version (версия операционной системы) позволяет указать версию операционной CM- 
стемы, под которой проявляется дефект. 

9. Product version (версия продукта) позволяет указать версию приложения, в которой был 
обнаружен дефект. 

10. Summary (краткое описание) позволяет указать краткое описание дефекта. 

11. Description (подробное описание) позволяет указать подробное описание дефекта. 

12. Steps to reproduce (шаги по воспроизведению) позволяет указать шаги по воспроизведению 
дефекта. 

13. Additional information (дополнительная информация) позволяет указать любую дополни- 
тельную информацию, которая может пригодиться при анализе и устранении дефекта. 

14. Upload file (загрузить файл) позволяет загрузить копии экрана и тому подобные файлы, 
которые могут быть полезны при анализе и устранении дефекта. 

15. View status (статус просмотра) позволяет управлять правами доступа к отчёту о дефекте и 
предлагает по умолчанию два варианта: 


• Public (публичный). 
e Private (закрытый). 


16. Report stay (остаться в режиме добавления отчётов) — отметка этого поля позволяет после 
сохранения данного отчёта сразу же начать писать следующий. 


циклом отчётов о дефектах, почитайте документацию по ним, посоздавайте в них не- 


© Задание 2.5.0: изучите ещё 3-5 инструментальных средств управления жизненным 
сколько отчётов о дефектах. 
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2.5.5. СВОЙСТВА КАЧЕСТВЕННЫХ 
ОТЧЕТОВ 0 ДЕФЕКТАХ шина 


Отчёт о дефекте может оказаться некачественным (а следовательно, вероятность исправления 
дефекта понизится), если в нём нарушено одно из следующих свойств. 


Тщательное заполнение всех полей точной и корректной информацией. Нарушение этого 
свойства происходит по множеству причин: недостаточный опыт тестировщика, невниматель- 
ность, лень и т.д. Самыми яркими проявлениями такой проблемы можно считать следующие: 


e Часть важных для понимания проблемы полей не заполнена. В результате отчёт превраща- 
ется в набор обрывочных сведений, использовать которые для исправления дефекта невоз- 
можно. 

• Предоставленной информации недостаточно для понимания сути проблемы. Например, 
из такого плохого подробного описания вообще не ясно, о чём идёт речь: «Приложение ино- 
гда неверно конвертирует некоторые файлы». 

• Предоставленная информация является некорректной (например, указаны неверные сооб- 
щения приложения, неверные технические термины и т.д.) Чаще всего такое происходит по 
невнимательности (последствия ошибочного COpy-paste и отсутствия финальной вычитки 
отчёта перед публикацией). 

e «Дефект» (именно так, в кавычках) найден в функциональности, которая ещё не была объ- 
явлена как готовая к тестированию. То есть тестировщик констатирует, что неверно работа- 
ет то, что и не должно было (пока!) верно работать. 

e В отчёте присутствует жаргонная лексика: как в прямом смысле — нелитературные выска- 
зывания, так и некие технические жаргонизмы, понятные крайне ограниченному кругу лю- 
дей. Например: «Фигово подцепились чартники». (Имелось в виду: «Не все таблицы кодиро- 
вок загружены успешно».) 

e Отчёт вместо описания проблемы с приложением критикует работу кого-то из участников 
проектной команды. Например: «Ну каким дураком надо быть, чтобы такое сделать?!» 

• В отчёте упущена некая незначительная на первый взгляд, но по факту критичная для BOC- 
произведения дефекта проблема. Чаще всего это проявляется в виде пропуска какого-то 
шага по воспроизведению, отсутствию или недостаточной подробности описания окруже- 
ния, чрезмерно обобщённом указании вводимых значений и т. п. 

e Отчёту выставлены неверные (как правило, заниженные) важность или срочность. Чтобы 
избежать этой проблемы, стоит тщательно исследовать дефект, определять его наиболее 
опасные последствия и аргументированно отстаивать свою точку зрения, если коллеги счи- 
тают иначе. 

• К отчёту не приложены необходимые копии экрана (особенно важные для косметических 
дефектов) или иные файлы. Классика такой ошибки: отчёт описывает неверную работу при- 
ложения с некоторым файлом, но сам файл не приложен. 

• Отчёт написан безграмотно с точки зрения человеческого языка. Иногда на это можно 34- 
крыть глаза, но иногда это становится реальной проблемой, например: «Not keyboard in 
parameters accepting values» (это реальная цитата; и сам автор так и не смог пояснить, что же 
имелось в виду). 


Правильный технический язык. Это свойство в равной мере относится и к требованиям, 
и ктест-кейсам, и к отчётам о дефектах — к любой документации, а потому не будем повторять- 
ся — см. описанное ранее!138}, 
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Сравните два подробных описания дефекта: 


Плохое подробное описание 


Хорошее подробное описание 


Когда мы как будто бы хотим убрать папку, 
где что-то внутри есть, оно не спрашивает, хо- 
тим ли мы. 


Не производится запрос подтверждения при 
удалении непустого подкаталога в каталоге 
SOURCE_DIR. 

Act: производится удаление непустого подка- 
талога (со всем его содержимым) в каталоге 
SOURCE_DIR без запроса подтверждения. 
Exp: в случае, если в каталоге SOURCE_DIR 
приложение обнаруживает непустой подката- 
лог, оно прекращает работу с выводом сооб- 
щения «Non-empty subfolder [имя подкатало- 
га] in SOURCE_DIR folder detected. Remove it 
manually or restart application with --force_file_ 
operations key to remove automatically.» 

Req: UR.56.BE.4.c. 


Специфичность описания шагов. Говоря о тест-кейсах, мы подчёркивали, что в их шагах CTO- 
ит придерживаться золотой середины между специфичностью и общностью. В отчётах о дефек- 


тах предпочтение, как правило, отдаётся специфичности по очень простой причине: нехватка 
какой-то мелкой детали может привести к невозможности воспроизведения дефекта. Потому, 
если у васесть хоть малейшее сомнение в том, важна ли какая-то деталь, считайте, что она важна. 


Сравните два набора шагов по воспроизведению дефекта: 


Недостаточно специфичные шаги 


Достаточно специфичные шаги 


1. Отправить на конвертацию файл допусти- 
мого формата и размера, в котором русский 
текст представлен в разных кодировках. 


Дефект: конвертация кодировок произво- 
дится неверно. 


1. Отправить на конвертацию файл в формате 
HTML размером от 100 КБ до 1 МБ, в кото- 
ром русский текст представлен в кодировках 
ОТЕЗ8 (10 строк по 100 символов) и WIN-1251 
(20 строк по 100 символов). 


Дефект: текст, который был представлен в 
ОТЕЗ8, повреждён (представлен нечитаемым 
набором символов). 


В первом случае воспроизвести дефект практически нереально, т.к. он заключается в особен- 
ностях работы внешних библиотек по определению кодировок текста в документе, в то время 
как во втором случае данных достаточно если и не для понимания сути происходящего (дефект 
на самом деле очень «хитрый»), то хотя бы для гарантированного воспроизведения и признания 


факта его наличия. 


Ещё раз главная мысль: в отличие от тест-кейса отчёт о дефекте может обладать повышенной 
специфичностью, и это будет меньшей проблемой, чем невозможность воспроизведения дефек- 
та из-за излишне обобщённого описания проблемы. 
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Отсутствие лишних действий и/или их длинных описаний. Чаще всего это свойство подра- 
зумевает, что не нужно в шагах по воспроизведению дефекта долго и по пунктам расписывать то, 


что можно заменить одной фразой: 


Плохо 


Хорошо 


1. Указать в качестве первого параметра прило- 
жения путь к папке с исходными файлами. 

2. Указать в качестве второго параметра прило- 

жения путь к папке с конечными файлами. 

3. Указать в качестве третьего параметра при- 
ложения путь к файлу журнала. 


. Запустить приложение. 


Дефект: приложение использует первый па- 
раметр командной строки и как путь к папке 
с исходными файлами, и как путь к папке с 
конечными файлами. 


1.Запустить приложение со всеми тремя 
корректными параметрами (особенно об- 
ратить внимание, чтобы SOURCE_DIR и 
DESTINATION_DIR не совпадали и не были 
вложены друг в друга в любом сочетании). 


Дефект: приложение прекращает рабо- 
ту с сообщением «SOURCE_DIR and 
DESTINATION_DIR may not Бе the same!» 
(судя по всему, первый параметр командной 
строки используется для инициализации 
имён обоих каталогов.) 


Вторая по частоте ошибка — начало каждого отчёта о дефекте с запуска приложения и под- 
робного описания по приведению его в то или иное состояние. Вполне допустимой практикой 
является написание в отчёте о дефекте приготовлений (по аналогии с тест-кейсами) или описа- 
ние нужного состояния приложения в одном (первом) шаге. 


Сравните: 


Плохо 


Хорошо 


1. Запустить приложение со всеми верными 
параметрами. 

2. Подождать более 30 минут. 

3. Передать на конвертацию файл допустимого 
формата и размера. 


Дефект: приложение не обрабатывает файл. 


Предусловие: приложение запущено и прора- 
ботало более 30 минут. 


1. Передать на конвертацию файл допустимого 
формата и размера. 


Дефект: приложение не обрабатывает файл. 


Отсутствие дубликатов. Когда в проектной команде работает большое количество тестиров- 
щиков, может возникнуть ситуация, при которой один и тот же дефект будет описан несколько 
раз разными ЛЮДЬМИ. А иногда бывает так, что даже один и тот же тестировщик уже забыл, что 
когда-то давно уже обнаруживал некую проблему, и теперь описывает её заново. Избежать по- 
добной ситуации позволяет следующий набор рекомендаций: 


• Если вы не уверены, что дефект не был описан ранее, произведите поиск с помощью вашего 
инструментального средства управления жизненным циклом отчётов о дефектах. 
• Пишите максимально информативные краткие описания (т.к. поиск в первую очередь про- 


водят по ним). Если на вашем проекте накопится множество дефектов с краткими описани- 


ями в стиле «Кнопка не работает», вы потратите очень много времени, раз за разом переби- 
рая десятки таких отчётов в поисках нужной информации. 


° Используйте по максимуму возможности вашего инструментального средства: указы- 


вайте в отчёте о дефекте компоненты приложения, ссылки на требования, расставляйте 


теги и т. д. — всё это позволит легко и быстро сузить в будущем круг поиска. 
e Указывайте в подробном описании дефекта текст сообщений от приложения, если это воз- 
можно. По такому тексту можно найти даже тот отчёт, в котором остальная информация 


приведена в слишком общем виде. 
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e Старайтесь по возможности участвовать в т.н. «собраниях по прояснению» (clarification 
тееН 155326), т.к. пусть вы и не запомните каждый дефект или каждую пользовательскую 
историю дословно, но в нужный момент может возникнуть ощущение «что-то такое я уже 
слышал», которое заставит вас произвести поиск и подскажет, что именно искать. 

• Если вы обнаружили какую-то дополнительную информацию, внесите её в уже сущест- 
вующий отчёт о дефекте (или попросите сделать это его автора), но не создавайте отдельный 
отчёт. 


Очевидность и понятность. Описывайте дефект так, чтобы у читающего ваш отчёт не воз- 
никло ни малейшего сомнения в том, что это действительно дефект. Лучше всего это свойство 
достигается за счёт тщательного объяснения фактического и ожидаемого результата, а также 
указания ссылки на требование в поле «Подробное описание». 


Сравните: 


Плохое подробное описание Хорошее подробное описание 


Приложение не сообщает об обнаруженных| Приложение не уведомляет пользователя об 
подкаталогах в каталоге SOURCE_DIR. обнаруженных в каталоге ЅООКСЕ РІК под- 
каталогах, что приводит к необоснованным 
ожиданиям пользователями обработки фай- 
лов в таких подкаталогах. 

Act: приложение начинает (продолжает) pa- 
боту, если в каталоге SOURCE_DIR находят- 
ся подкаталоги. 

Exp: в случае если в каталоге SOURCE_DIR 
приложение при запуске или в процессе 
работы обнаруживает пустой подкаталог, 
оно автоматически его удаляет (логично ли 
это?), если же обнаружен непустой подката- 
лог, приложение прекращает работу с выво- 
дом сообщения «Non-empty subfolder [имя 
подкаталога| in SOURCE_DIR folder detected. 
Remove it manually or restart application 
with -- force_file_operations key to remove 
automatically.» 

Req: ОК.56.ВЕ4.с. 


В первом случае после прочтения подробного описания очень хочется спросить: «И что? А оно 
разве должно уведомлять?» Второй же вариант подробного описания даёт чёткое пояснение, 
что такое поведение является ошибочным согласно текущему варианту требований. Более того, 
во втором варианте отмечен вопрос (а в идеале нужно сделать соответствующую отметку и в 
самом требовании), призывающий пересмотреть алгоритм корректного поведения приложения 
в подобной ситуации: т.е. мы не только качественно описываем текущую проблему, но и подни- 
маем вопрос о дальнейшем улучшении приложения. 


Прослеживаемость. Из содержащейся в качественном отчёте о дефекте информации должно 
быть понятно, какую часть приложения, какие функции и какие требования затрагивает дефект. 
Лучше всего это свойство достигается правильным использованием возможностей инструмен- 
тального средства управления отчётами о дефектах: указывайте в отчёте о дефекте компоненты 


326 Clarification meeting. А discussion that helps the customers achieve “advance clarity” — consensus оп the desired 
behavior of each story — by asking questions and getting examples. [«Agile Testing», Lisa Crispin, Janet Gregory] 
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приложения, ссылки на требования, тест-кейсы, смежные отчёты о дефектах (похожих дефектах; 
зависимых и зависящих от данного дефектах), расставляйте теги и т. д. 

Некоторые инструментальные средства даже позволяют строить визуальные схемы на основе 
таких данных, что позволяет управление прослеживаемостью даже на очень больших проектах 
превратить из непосильной для человека задачи в тривиальную работу. 


Отдельные отчёты для каждого нового дефекта. Существует два незыблемых правила: 


• В каждом отчёте описывается ровно один дефект (если один и тот же дефект проявляется в 
нескольких местах, эти проявления перечисляются в подробном описании). 

• При обнаружении нового дефекта создаётся новый отчёт. Нельзя для описания нового де- 
фекта править старые отчёты, переводя их в состояние «открыт заново». 


Нарушение первого правила приводит к объективной путанице, которую проще всего проил- 
люстрировать так: представьте, что в одном отчёте описано два дефекта, один из которых был 
исправлен, а второй — нет. В какое состояние переводить отчёт? Неизвестно. 

Нарушение второго правила вообще порождает хаос: мало того, что теряется информация о 
ранее возникавших дефектах, так к тому же возникают проблемы со всевозможными метриками 
и банальным здравым смыслом. Именно во избежание этой проблемы на многих проектах пра- 
вом перевода отчёта из состояния «закрыт» в состояние «открыт заново» обладает ограничен- 
ный круг участников команды. 


Соответствие принятым шаблонам оформления и традициям. Как и в случае с тест-кейса- 
ми, с шаблонами оформления отчётов о дефектах проблем не возникает: они определены имею- 
щимся образцом или экранной формой инструментального средства управления жизненным 
циклом отчётов о дефектах. Но что касается традиций, которые могут различаться даже в разных 
командах в рамках одной компании, то единственный совет: почитайте уже готовые отчёты о 
дефектах, перед тем как писать свои. Это может сэкономить вам много времени и сил. 
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2.5.6. ЛОГИКА СОЗДАНИЯ ЭФФЕКТИВНЫХ ОТЧЁТОВ 
0 ДЕФЕКТАХ ШЕШ 


При создании отчёта о дефекте рекомендуется следовать следующему алгоритму: 


0. Обнаружить дефект ©. 

1. Понять суть проблемы. 

2. Воспроизвести дефект. 

3. Проверить наличие описания найденного вами дефекта в системе управления дефектами. 

4. Сформулировать суть проблемы в виде «что сделали, что получили, что ожидали получить». 

5. Заполнить поля отчёта, начиная с подробного описания. 

6. После заполнения всех полей внимательно перечитать отчёт, исправив неточности и доба- 
вив подробности. 

7. Ещё раз перечитать отчёт, т.к. в пункте 6 вы точно что-то упустили ©). 


Теперь — о каждом шаге подробнее. 


ПОНЯТЬ СУТЬ ПРОБЛЕМЫ 


Всё начинается именно с понимания происходящего с приложением. Только при наличии 
такого понимания вы сможете написать по-настоящему качественный отчёт о дефекте, верно 
определить важность дефекта и дать полезные рекомендации по его устранению. В идеале отчёт 
о дефекте описывает именно суть проблемы, а не её внешнее проявление. 

Сравните два отчёта об одной и той же ситуации (приложение «Конвертер файлов» не раз- 
личает файлы и символические ссылки на файлы, что приводит к серии аномалий в работе с 
файловой системой). 


Плохой отчёт, при написании которого суть проблемы не понята: 


Краткое описание Подробное описание Шаги по воспроизведению 
Обрабатывают- Иногда по непонятным причинам прило-|К сожалению, не удалось 
ся файлы вне жение обрабатывает случайные файлы вне| обнаружить последователь- 
SOURCE_DIR. каталога SOURCE_DIR. ность шагов, приводящих K 
Act: обрабатываются отдельные файлы вне | появлению этого дефекта. 
SOURCE_DIR. 
Exp: обрабатываются только файлы, нахо- 
дящиеся в SOURCE_DIR. 
Req: ДС-2.1. 
Воспроиз- | Важность | Срочность | Симптом | Возмож- Комментарий 
водимость ность 
обойти 
Иногда Высокая |Высокая Некор- Нет 
ректная 
операция 
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Хороший отчёт, при написании которого суть проблемы понята: 


Краткое описание 


Подробное описание 


Шаги по воспроизведению 


Приложение не 
различает файлы 
и симоволические 
ссылки на файлы. 


Если в каталог SOURCE_DIR поместить 
символическую ссылку на файл, возникает 
следующее ошибочное поведение: 

а) Если символическая ссылка указывает на 
файл внутри SOURCE_DIR, файл обраба- 
тывается дважды, а в DESTINATION_DIR 
перемещается как сам файл, так и символи- 
ческая ссылка на него. 

6) Если символическая ссылка указыва- 
ет на файл вне SOURCE_DIR, приложе- 
ние обрабатывает этот файл, перемеща- 
ет символическую ссылку и сам файл в 
DESTINATION_DIR, а затем продолжает 
обрабатывать файлы в каталоге, в котором 
изначально находился обработанный файл. 
Act: приложение считает символические 
ссылки на файлы самими файлами (см. под- 
робности выше). 

Exp: в случае если в каталоге SOURCE_DIR 
приложение обнаруживает символиче- 
скую ссылку, оно прекращает работу с 
выводом сообщения «Symbolic link [имя 
символической ссылки] іп ЅООКСЕ РІК 
folder detected. Remove it manually ог restart 
application with --force_file_operations key to 
remove automatically.» 

Req: ОК.56.ВЕ4.е. 


1. В произвольном месте C03- 


дать следующую структуру 
каталогов: 

/5ВС/ 

/DST/ 

/Х/ 

. Поместить в каталоги SRC и 
Х несколько произвольных 
файлов допустимого фор- 
мата и размера. 

‚Создать в каталоге SRC 
две символические ссыл- 
ки: а) на любой из фай- 
лов внутри каталога SRC; 
6) на любой из файлов 
внутри каталога Х. 


4. Запустить приложение. 


Дефект: в каталог DST ne- 
ремещены как файлы, так 
и символические ссылки; 
содержимое каталога Х об- 
работано и перемещено в 
каталог DST. 


Воспроиз- | Важность | Срочность | Симптом | Возмож- Комментарий 
водимость ность 
обойти 
Всегда Высокая |Обычная |Некор- |Нет Быстрый взгляд на код показал, что 
ректная вместо is_file() используется Ше_ 
операция exists(). Похоже, проблема в этом. 


Также этот дефект приводит к попыт- 
ке обработать каталоги как файлы 
(см. ВВ-999.99). В алгоритме обработ- 
ки SOURCE_DIR явно есть логиче- 
ская ошибка: ни при каких условиях 
приложение не должно обрабатывать 
файлы, находящиеся вне ЗОЧВСЕ_ 
DIR, т.е. что-то не так с генерацией 
или проверкой полных имён файлов. 
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ВОСПРОИЗВЕСТИ ДЕФЕКТ 


Это действие не только поможет в дальнейшем правильно заполнить поле «Воспроизводи- 
мость179}», но и позволит избежать неприятной ситуации, в которой за дефект приложения 
будет принят некий кратковременный сбой, который (скорее всего) произошёл где-то в вашем 
компьютере или в иной части ИТ-инфраструктуры, не имеющей отношения к тестируемому 
приложению. 


ПРОВЕРИТЬ НАЛИЧИЕ ОПИСАНИЯ НАЙДЕННОГО ВАМИ ДЕФЕКТА 


Обязательно стоит проверить, нет ли в системе управления дефектами описания именного 
того дефекта, который вы только что обнаружили. Это простое действие, не относящееся непо- 
средственно к написанию отчёта о дефекте, но значительно сокращающее количество отчётов, 
отклонённых с резолюцией «дубликат». 


СФОРМУЛИРОВАТЬ СУТЬ ПРОБЛЕМЫ 


Формулировка проблемы в виде «что сделали (шаги по воспроизведению), что получили 
(фактический результат в подробном описании), что ожидали получить (ожидаемый результат 
в подробном описании)» позволяет не только подготовить данные для заполнения полей отчёта, 
но и ещё лучше понять суть проблемы. 

В общем же случае формула «что сделали, что получили, что ожидали получить» хороша по 
следующим причинам: 


• Прозрачность и понятность: следуя этой формуле, вы готовите именно данные для отчёта о 
дефекте, не скатываясь в пространные отвлечённые рассуждения. 

• Лёгкость верификации дефекта: разработчик, используя эти данные, может быстро воспро- 
извести дефект, а тестировщик после исправления дефекта удостовериться, что тот действи- 
тельно исправлен. 

e Очевидность для разработчиков: ещё до попытки воспроизведения дефекта видно, на самом 
ли деле описанное является дефектом, или тестировщик где-то ошибся, записав в дефекты 
корректное поведение приложения. 

• Избавление от лишней бессмысленной коммуникации: подробные ответы на «что сделали, 
что получили, что ожидали получить» позволяют решать проблему и устранять дефект без 
необходимости запроса, поиска и обсуждения дополнительных сведений. 

• Простота: на финальных стадиях тестирования с привлечением конечных пользователей 
можно ощутимо повысить эффективность поступающей обратной связи, если объяснить 
пользователям суть этой формулы и попросить их придерживаться её при написании сооб- 
щений об обнаруженных проблемах. 


Информация, полученная на данном этапе, становится фундаментом для всех дальнейших 
действий по написанию отчёта. 


ЗАПОЛНИТЬ ПОЛЯ ОТЧЁТА 


Поля отчёта о дефекте мы уже рассмотрели ранее!175), сейчас лишь подчеркнём, что начинать 
лучше всего с подробного описания, т.к. в процессе заполнения этого поля может выявиться 
множество дополнительных деталей, а также появятся мысли по поводу формулирования сжа- 
того и информативного краткого описания. 

Если вы понимаете, что для заполнения какого-то поля у вас не хватает данных, проведите 
дополнительное исследование. Если и оно не помогло, опишите в соответствующем поле (если 
оно текстовое), почему вы затрудняетесь с его заполнением, или (если поле представляет собой 
список) выберите значение, которое, на ваш взгляд, лучше всего характеризует проблему (в не- 
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которых случаях инструментальное средство позволяет выбрать значение наподобие «неизвест- 
но», тогда выберите его). 

Если у вас нет идей по поводу устранения дефекта, или он настолько тривиален, что не нужда- 
ется в подобных пояснениях, не пишите в комментариях «текст ради текста»: комментарии вида 
«рекомендую устранить этот дефект» не просто бессмысленны, но ещё и раздражают. 


ПЕРЕЧИТАТЬ ОТЧЁТ (И ЕЩЁ РАЗ ПЕРЕЧИТАТЬ ОТЧЁТ) 


После того как всё написано, заполнено и подготовлено, ещё раз внимательно перечитайте на- 
писанное. Очень часто вы сможете обнаружить, что в процессе доработки текста где-то получи- 
лись логические нестыковки или дублирование, где-то вам захочется улучшить формулировки, 
где-то что-то поменять. 

Идеал недостижим, и не стоит тратить вечность на один отчёт о дефекте, но и отправлять не- 
вычитанный документ — тоже признак дурного тона. 

“= После оформления отчёта о дефекте рекомендуется дополнительно исследовать ту 
© область приложения, в которой вы только что обнаружили дефект. Практика показы- 
вает, что дефекты часто проявляются группами. 
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2.5.7. ТИПИЧНЫЕ ОШИБКИ ПРИ НАПИСАНИИ ОТЧЁТОВ 
0 ДЕФЕКТАХ шшш 


Перед прочтением этого текста рекомендуется перечитать раздел с описанием типичных оши- 
бок при составлении тест-кейсов и чек-листов 61, т. к. многие описанные там проблемы акту- 
альны и для отчётов о дефектах (ведь и то, и другое — специфическая техническая докумен- 
тация). 


ОШИБКИ ОФОРМЛЕНИЯ И ФОРМУЛИРОВОК 


Плохие краткие описания (summary). Формально эта проблема относится к оформлению, но 
фактически она куда опаснее: ведь чтение отчёта о дефекте и осознание сути проблемы начина- 
ется именно с краткого описания. Ещё раз напомним его суть: 


• Отвечает на вопросы «что?», «где?», «при каких условиях». 
e Должно быть предельно кратким. 
• Должно быть достаточно информативным для понимания сути проблемы. 


Посмотрите на эти краткие описания и попробуйте ответить себе на вопрос о том, что за 
проблема возникает, где она возникает, при каких условиях она возникает: 


• «Неожиданное прерывание». 

• «Найдено 19 элементов». 

• «Поиск по всем типам файлов». 

• «Неинформативная ошибка». 

• «В приложении красный шрифт». 

• «Error when entering just ше пате оў computer disk от folder». 
• «No reaction to Enter key». 


Иногда ситуацию спасает поле «подробное описание», из которого можно понять суть 
проблемы, но даже в этом случае сначала нужно приложить немало усилий, чтобы соотнести 
такое краткое описание с подробным, где представлено совершенно иное и иначе. 

Перечитайте ещё раз раздел про формулировку качественных кратких описаний 76}. 


Идентичные краткое и подробное описания (summary и description). Да, изредка быва- 
ют настолько простые дефекты, что для них достаточно одного краткого описания (например, 
«Опечатка в имени пункта главного меню “File” (сейчас “ЕШе”)»), но если дефект связан с неким 
более-менее сложным поведением приложения, стоит продумать как минимум три способа опи- 
сания проблемы: 

e краткий для поля «краткое описание» (его лучше формулировать в самом конце размыш- 

лений); 

» подробный для поля «подробное описание» (поясняющий и расширяющий информацию из 

«краткого описания»); 
• ещё один краткий для последнего шага в шагах по воспроизведению дефекта. 


И это не интеллектуальные игры от переизбытка свободного времени, это вполне рабочий 
инструмент для формирования понимания сути проблемы (поверьте, вы едва ли сможете объяс- 
нить тремя разными способами то, что не понимаете). 


Отсутствие в подробном описании явного указания фактического результата, ожидаемого 
результата и ссылки на требование, если они важны, и их представляется возможным указать. 
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Да, для мелочей наподобие опечаток в надписях этого можно не делать (и всё равно: при нали- 
чии времени лучше написать). 

Но что можно понять из отчёта о дефекте, в кратком и подробном описании которого сказано 
только «приложение показывает содержимое ОрепХМІ-файлов»? А что, не должно показывать? 
В чём вообще проблема? Ну, показывает и показывает — разве это плохо? Ах, оказывается (!), 
приложение должно не показывать содержимое этих файлов, а открывать их с помощью соот- 
ветствующей внешней программы. Об этом можно догадаться из опыта. Но догадка — плохой 
помощник в случае, когда надо переписывать приложение, — можно сделать только хуже. Это 
также можно (наверное) понять, вдумчиво читая требования. Но давайте будем реалистами: 
отчёт о дефекте будет отклонён с резолюцией «описанное поведение не является дефектом» 
(«not а bug»). 


Игнорирование кавычек, приводящее к искажению смысла. Как вы поймёте такое краткое 
описание, как «запись исчезает при наведении мыши»? Какая-то запись исчезает при наведении 
мыши? А вот и нет, оказывается, «поле “Запись” исчезает при наведении мыши». Даже если не 
дописать слово «поле», кавычки подскажут, что имеется в виду имя собственное, т.е. название 
некоего элемента. 


Общие проблемы с формулировками фраз на русском и английском языках. Да, нелегко 
сразу научиться формулировать мысль одновременно очень кратко и информативно, но не ме- 
нее сложно читать подобные творения (цитаты дословные): 


• «Поиск не работает нажатием кнопки Enter». 

• «По умолчанию в поле где искать стоит +». 

• «При поиске файлов в обширном каталоге приложение ненадолго «зависает»». 

• «При закрытии ошибки программа закрывается». 

• «The application doesn’t work with ше from keyboard by the user іп the field «What to зеатсй»». 


Лишние пункты в шагах воспроизведения. Не стоит начинать «с сотворения мира», боль- 
шинство проектной команды достаточно хорошо знает приложение, чтобы «опознать» его клю- 


чевые части, потому — сравните: 


Плохо Хорошо 
1. Запустить приложение. 1. Создать или открыть файл с тремя и более 
2. Открыть пункт меню «Файл». непустыми страницами. 
3. Выбрать пункт меню «Новый». 2. Выбрать «Файл» -> «Печать» -> 
4. Заполнить текстом не менее трёх страниц. «Параметры» -> «Двусторонняя печать» -> 
5. Открыть пункт меню «Файл». «Нет». 
6. Открыть подпункт меню «Печать». 3. Распечатать документ на принтере, поддер- 
7. Открыть вкладку «Параметры печати». живающем дуплексную печать. 
8. Выбрать в списке «Двусторонняя печать» 


Дефект: печать по-прежнему двусторонняя. 
значение «Нет». 


. Распечатать документ на принтере, поддер- 
живающем дуплексную печать. 


© 


Дефект: печать по-прежнему двусторонняя. 


Копии экрана в виде «копий всего экрана целиком». Чаще всего нужно сделать копию како- 
го-то конкретного окна приложения, а не всего экрана — тогда поможет Alt+PrintScreen. Даже 
если важно захватить больше, чем одно окно, практически любой графический редактор позво- 
ляет отрезать ненужную часть картинки. 


Копии экрана, на которых не отмечена проблема. Если обвести проблемную область крас- 
ной линией, это в разы повысит скорость и простоту понимания сути проблемы В большинстве 
случаев. 
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22 Копии экрана и иные артефакты, размещённые на сторонних серверах. Эта ошибка 

О заслуживает особого упоминания: категорически запрещено использовать для при- 
крепления к отчёту о дефекте копий экрана и других файлов ставшие распростра- 
нёнными в последнее время сервисы обмена изображениями, файлами и т.д. Причин 
здесь две: 

• в большинстве случаев на размещение изображения или иного файла на таких сер- 
висах есть ограничения по времени хранения и/или количеству обращений (скачи- 
ваний) — иными словами, через некоторое время файл может стать недоступным; 

• размещение информации о проекте на сторонних сервисах является раскрытием 
конфиденциальной информации, права на которую принадлежат заказчику. 


Потому для хранения любых подобных артефактов следует использовать саму систему 
управления дефектами. Если в силу неких причин таковая не используется, все вложе- 
ния стоит разместить прямо в том документе, в котором вы описываете дефект (изо- 
бражения можно разместить просто «в виде картинок», иные артефакты — в виде вне- 
дрённого документа). 


Откладывание написания отчёта «на потом». Стремление сначала найти побольше дефек- 
тов, а уже потом их описывать приводит к тому, что какие-то важные детали (а иногда и сами 
дефекты!) забываются. Если «на потом» измеряется не минутами, а часами или даже днями, про- 
ектная команда не получает важную информацию вовремя. Вывод простой: описывайте дефект 
сразу же, как только обнаружили его. 


Пунктуационные, орфографические, синтаксические и им подобные ошибки. Без коммен- 
тариев. 


ЛОГИЧЕСКИЕ ОШИБКИ 


Выдуманные дефекты. Одной из наиболее обидных для тестировщика причин отклоне- 
ния отчёта о дефекте является так называемое «описанное поведение не является дефектом» 
(«not а bug»), когда по какой-то причине корректное поведение приложения описывается как 
ошибочное. 

Но ещё хуже, когда «якобы ожидаемое поведение» просто... придумывается из головы. 
То есть нигде в требованиях не сказано, что приложение должно что-то такое делать, но при 
этом создаётся отчёт о дефекте из-за того, что приложение этого не делает. И ладно бы это были 
некие спорные случаи или случайно попавшие в отчёты о дефектах предложения по улучшению, 
но нет — от приложения начинают требовать каких-то совершенно нелогичных, нерациональ- 
ных, безумных вещей. Откуда это? Зачем? Просто не делайте так. 


Отнесение расширенных возможностей приложения к дефектам. Самым ярким примером 
этого случая является описание как дефекта того факта, что приложение запускается под опера- 
ционными системами, не указанными явно в списке поддерживаемых. Лишь в очень редких слу- 
чаях при разработке неких системных утилит и тому подобного ПО, крайне зависящего от вер- 
сии ОС и потенциально способного «поломать» неподдерживаемую, это можно считать ошибкой 
(с точки зрения общего здравого смысла такое приложение действительно должно показывать 
предупреждение или даже сообщение об ошибке и завершать работу на неподдерживаемой ОС). 
Но что плохого в том, что детская игрушка запустилась на ОС предыдущего поколения? Это ре- 
ально проблема?! Сомнительно. 


Неверно указанные симптомы. Это не смертельно, всегда можно подправить, но если изна- 
чально отчёты будут сгруппированы по симптомам, это создаёт множество раздражающих не- 
удобств. 
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Чрезмерно заниженные (или завышенные) важность и срочность. С этой бедой достаточно 
эффективно борются проведением общих собраний и пересмотром отчётов о дефектах сила- 
ми всей команды (или хотя бы нескольких человек), но если эти показатели занижены именно 
чрезмерно, есть высокая вероятность, что пройдёт очень много времени, прежде чем до такого 
отчёта просто дойдёт очередь на следующих собраниях по пересмотру. 


Концентрация на мелочах в ущерб главному. Здесь стоит упомянуть хрестоматийный при- 
мер, когда тестировщик нашёл проблему, приводящую к краху приложения с потерей пользо- 
вательских данных, но записал её как косметический дефект (в сообщении об ошибке, которое 
«перед смертью» показывало приложение, была опечатка). Всегда думайте о том, как произошед- 
шая с приложением неприятность повлияет на пользователей, какие сложности они могут из-за 
этого испытать, насколько это для них важно, — тогда шанс увидеть реальную проблему резко 
повышается. 


Техническая безграмотность. Да, вот так безапелляционно и жёстко. В некоторых случаях 
она просто вызывает грустную улыбку, но в некоторых... Представьте себе такое краткое описа- 
ние (оно же идентично продублировано в подробном, т.е. это и есть всё описание дефекта): «Ко- 
личество найденных файлов не соответствует реальной глубине вложенности каталога». А что, 
должно? Это ведь почти то же самое, что «цвет кошки не соответствует её размеру». 

Ещё несколько показательных примеров (это примеры из разных, никак не связанных между 
собой отчётов о дефектах): 


• Краткое описание: «По умолчанию выбран каталог аудиозаписи». (На самом деле в выпа- 
дающем списке «Что искать» выбрано значение «Аудиофайлы».) 

• Пояснение в подробном описании: «У каталога не может быть даты и времени создания». 
(Хм. Может.) 

• Ожидаемый результат: «Приложение верно распознало неподдерживаемую файловую си- 
стему и показало список файлов». (Ого! С этим приложением, скорее всего, можно будет и 
на философские темы побеседовать, если оно способно на такую магию.) 


Указание в шагах воспроизведения информации, неважной для воспроизведения ошибки. 
Стремление прописать всё максимально подробно иногда принимает нездоровую форму, когда в 
отчёт о дефекте начинает попадать чуть ли не информация о погоде за окном и курс националь- 
ной валюты. Сравните: 


Плохо Хорошо 


1. Создать на диске «):» каталог «Data». 1. В произвольном месте на локальном диске 
2. Разместить в созданном каталоге «Data»| разместить один (или более) файл с расши- 
прилагаемые файлы «songl.mp3» размером | рением «.mp3». 
999.99 Kb и «song2.mp3» размером 888.88 КЬ. | 2. Установить параметры поиска 


3. В поле «Где искать» указать «Ј:\Раѓа». («Что искать» -> «Аудиофайлы», 

4. В выпадающем списке «Что искать» выбрать | «Где искать» -> место расположения 
«Аудиофайлы». файла(ов) из пункта 1). 

5. Нажать кнопку «Искать». 3. Произвести поиск. 


Дефект: указанные в пункте 2 файлы не най-| Дефект: приложение не обнаруживает фай- 
дены. лы с расширением «.mp3». 


Действительно ли для воспроизведения дефекта важно, чтобы поиск производился на дис- 
ке «]:»? Действительно ли важно производить поиск именно файлов с такими именами и разме- 
рами в таком каталоге? Возможно, в некоем бесконечно маловероятном случае и да, тогда вопрос 
снимается. Но, скорее всего, это совершенно не важно, и нет никакой необходимости записывать 
эту информацию. Для большей уверенности можно провести дополнительное исследование. 
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Игнорирование т.н. «последовательных дефектов». Иногда один дефект является следстви- 
ем другого (допустим, файл повреждается при передаче на сервер, а затем приложение некор- 
ректно обрабатывает этот повреждённый файл). Да, если файл будет передан без повреждений, 
второй дефект может не проявиться. Но может и проявиться в другой ситуации, т.к. проблема 
никуда не исчезла: приложение некорректно обрабатывает повреждённые файлы. Потому стоит 
описать оба дефекта. 


Отсутствие в шагах воспроизведения информации, важной для воспроизведения дефек- 
та. Нет, мы не издеваемся, этот пункт действительно строго противоположен предыдущему. Де- 
фекты бывают разными. Очень разными. Иногда какой-то ключевой «мелочи» не хватит, чтобы 
разработчику удалось воспроизвести дефект или даже просто понять его суть. Несколько реаль- 
ных примеров (подчёркнуты те детали, отсутствие которых долго не позволяло воспроизвести 
дефект): 

• Приложение не сохраняло пользовательские настройки в случае, если в пути к каталогу для 

их сохранения были пробелы (два и более подряд пробела). 

e Приложение некорректно завершало работу при открытии файлов, размер которых не 
позволял прочитать их целиком в оперативную память, доступный объём которой, в свою 
очередь, определяется значением параметра memory limit B настройках среды исполнения. 

• Приложение отображало неверную статистику работы пользователей, если в системе был 
хотя бы один пользователь, роль которого не была явно указана (NULL-3Hayenne в таблице 
БД, неверная работа подзапроса). 


Как понять, насколько подробно надо описывать такие детали? Исследованием. Мало просто 
обнаружить некий единичный случай неверного поведения приложения, нужно понять законо- 
мерность такого поведения и его источник. Тогда необходимая степень детализации становится 
очевидной. 

Сюда же можно отнести пресловутую воспроизводимость «иногда». Нужно продолжать ис- 
кать причины, смотреть код, консультироваться с коллегами, проводить дополнительные тесты, 
исследовать похожую функциональность в других частях приложения, исследовать аналогичные 
приложения, «гуглить» и т.д. и т.п. Да, часть дефектов оказывается сильнее даже самых упорных 
тестировщиков, но вот процент таких дефектов можно очень сильно приблизить к нулю. 
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ОЦЕНКА ТРУДОЗАТРАТ, _ 
ПЛАНИРОВАНИЕ И ОТЧЕТНОСТЬ 


2.6.1. ПЛАНИРОВАНИЕ И ОТЧЕТНОСТЬ immm 


В главе «Логика создания эффективных проверок» 153} мы на примере «Конвертера файлов» 
рассуждали о том, как при минимальных трудозатратах получить максимальный эффект от тес- 
тирования. Это было достаточно просто, т.к. наше приложение смехотворно по своим масшта- 
бам. Но давайте представим, что тестировать приходится реальный проект, где требования в 
«страничном эквиваленте» занимают сотни и даже тысячи страниц. Также давайте вспомним 
главу «Подробная классификация тестирования»{68} с её несколькими десятками видов тести- 
рования (и это без учёта того факта, что их можно достаточно гибко комбинировать, получая 
новые варианты) и подумаем, как применить все эти знания (и открываемые ими возможности) 
в крупном проекте. 

Даже если допустить, что мы идеально знаем все технические аспекты предстоящей работы, 
неотвеченными остаются такие вопросы, как: 


• Когда и с чего начать? 

• Всё ли необходимое для выполнения работы у нас есть? Если нет, где взять недостающее? 

• В какой последовательности выполнять разные виды работ? 

• Как распределить ответственность между участниками команды? 

e Как организовать отчётность перед заинтересованными лицами? 

e Как объективно определять прогресс и достигнутые успехи? 

• Как заранее увидеть возможные проблемы, чтобы успеть их предотвратить? 

e Как организовать нашу работу так, чтобы при минимуме затрат получить максимум резуль- 
тата? 


Эти и многие подобные им вопросы уже лежат вне технической области — они относятся к 
управлению проектом. Эта задача сама по себе огромна, потому мы рассмотрим лишь малую её 
часть, с которой многим тестировщикам приходится иметь дело, — планирование и отчётность. 

Вспомним жизненный цикл тестирования 0}: каждая итерация начинается с планирования 
и заканчивается отчётностью, которая становится основой для планирования следующей ите- 
рации — и так далее (см. рисунок 2.6.а). Таким образом, планирование и отчётность находятся 
в тесной взаимосвязи, и проблемы с одним из этих видов деятельности неизбежно приводят к 
проблемам с другим видом, а в конечном итоге и к проблемам с проектом в целом. 


Если выразить эту мысль чётче и по пунктам, получается: 


e Без качественного планирования не ясно, кому и что нужно делать. 

° Когда не ясно, кому и что нужно делать, работа выполняется плохо. 

° Когда работа выполнена плохо и не ясны точные причины, невозможно сделать правильные 
выводы о том, как исправить ситуацию. 

e Без правильных выводов невозможно создать качественный отчёт о результатах работы. 
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—> 


Отчётность Планирование 


Работа 


Рисунок 2.6.а — Взаимосвязь (взаимозависимость) планирования и отчётности 


e Без качественного отчёта о результатах работы невозможно создать качественный план 
дальнейшей работы. 
• Всё. Порочный круг замкнулся. Проект умирает. 


Казалось бы, так и в чём же сложность? Давайте будем хорошо планировать и писать каче- 
ственные отчёты — и всё будет хорошо. Проблема в том, что соответствующие навыки развиты 
в достаточной мере у крайне небольшого процента людей. Если вы не верите, вспомните, как 
учили материал В НОЧЬ перед экзаменом, как опаздывали на важные встречи Из повторяли это 
раз за разом, так и не сделав выводов. (Если В вашей жизни такого не было, можно надеяться, что 
вам повезло оказаться в том небольшом проценте людей, у которых соответствующие навыки 
развиты хорошо.) 

Корень проблемы СОСТОИТ В ТОМ, ЧТО планированию и отчётности в школах и университетах 
учат достаточно поверхностно, при этом (увы) на практике часто выхолащивая эти понятия до 
пустой формальности (планов, на которые никто не смотрит, и отчётов, которые никто не чита- 
ет; опять же, кому-то повезло увидеть строго обратную ситуацию, но явно немногим). 

Итак, к сути. Сначала рассмотрим классические определения. 


шений и методической организации усилий по их реализации с целью обеспечения 


© Планирование (planning???) — непрерывный процесс принятия управленческих pe- 
качества некоторого процесса на протяжении длительного периода времени. 


327 Planning is а continuous process of making entrepreneurial decisions with ап eye to the future, and methodically 
organizing the effort needed to carry out these decisions. There are four basic reasons for project planning: to eliminate or 
reduce uncertainty; to improve efficiency of the operation; to obtain a better understanding of the objectives; to provide a basis 
for monitoring and controlling work. [«Project Management: A Systems Approach to Planning, Scheduling, and Controlling», 
Harold Kerzner] 
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К высокоуровневым задачам планирования относятся: 


• снижение неопределённости; 

• повышение эффективности; 

• улучшение понимания целей; 

• создание основы для управления процессами. 


Отчётность (герог 9328) — сбор и распространение информации о результатах pabo- 
ТЫ (включая текущий статус, оценку прогресса и прогноз развития ситуации). 


К высокоуровневым задачам отчётности относятся: 


e сбор, агрегация и предоставление в удобной для восприятия форме объективной информа- 
ции о результатах работы; 

e формирование оценки текущего статуса и прогресса (в сравнении с планом); 

• обозначение существующих и возможных проблем (если такие есть); 

e формирование прогноза развития ситуации и фиксация рекомендаций по устранению 
проблем и повышению эффективности работы. 


Как и было упомянуто ранее, планирование и отчётность относятся к области управления 
проектом, которая выходит за рамки данной книги. 


источниками информации: 

e «Project Management: А Systems Approach to Planning, Scheduling, and Controlling», 
Harold Kerzner. 

e PMBOK («Project Management Body of Knowledge»). 


© Если вас интересуют детали, рекомендуется ознакомиться с двумя фундаментальными 


Мы же переходим к более конкретным вещам, с которыми приходится работать (пусть и на 
уровне использования, а не создания) даже начинающему тестировщику. 


328 Reporting — collecting апа distributing performance information (including status reporting, progress measurement, 
and forecasting). [PMBOK, 3rd edition] 
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2.6.2. ТЕСТ-ПЛАН И ОТЧЁТ 
0 РЕЗУЛЬТАТАХ ТЕСТИРОВАНИЯ Namm 


ТЕСТ-ПЛАН 


работ по тестированию, а также соответствующие техники и подходы, стратегию, об- 


Ө Тест-план (test plan???) — документ, описывающий и регламентирующий перечень 
ласти ответственности, ресурсы, расписание и ключевые даты. 


К низкоуровневым задачам планирования в тестировании относятся: 


• оценка объёма и сложности работ; 

e определение необходимых ресурсов и источников их получения; 

• определение расписания, сроков и ключевых точек; 

e оценка рисков и подготовка превентивных контрмер; 

• распределение обязанностей и ответственности; 

• согласование работ по тестированию с деятельностью участников проектной команды, за- 
нимающихся другими задачами. 


Как и любой другой документ, тест-план может быть качественным или обладать недостат- 
ками. Качественный тест-план обладает большинством свойств качественных требований! 4, 
а также расширяет их набор следующими пунктами: 

e Реалистичность (запланированный подход реально выполним). 

• Гибкость (качественный тест-план не только является модифицируемым с точки зрения pa- 
боты с документом, но и построен таким образом, чтобы при возникновении непредви- 
денных обстоятельств допускать быстрое изменение любой из своих частей без нарушения 
взаимосвязи с другими частями). 

e Согласованность с общим проектным планом и иными отдельными планами (например, 
планом разработки). 


Тест-план создаётся в начале проекта и дорабатывается по мере необходимости на протяже- 
нии всего времени жизни проекта при участии наиболее квалифицированных представителей 
проектной команды, задействованных в обеспечении качества. Ответственным за создание 
тест-плана, как правило, является ведущий тестировщик («тест-лид»). 


В общем случае тест-план включает следующие разделы (примеры их наполнения будут пока- 
заны далее, потому здесь — только перечисление). 


• Цель (purpose). Предельно краткое описание цели разработки приложения (частично это 
напоминает бизнес-требования 9}, но здесь информация подаётся в ещё более сжатом виде 
и вконтексте того, на что следует обращать первостепенное внимание при организации тес- 
тирования и повышения качества). 

• Области, подвергаемые тестированию (features to Бе tested). Перечень функций и/или ne- 
функциональных особенностей приложения, которые будут подвергнуты тестированию. 
В некоторых случаях здесь также приводится приоритет соответствующей области. 


329 Test plan. А document describing the scope, approach, resources and schedule of intended test activities. It identifies 
amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the 
test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any 
risks requiring contingency planning. It is a record of the test planning process. [ISTQB Glossary] 
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• Области, не подвергаемые тестированию (features not to be tested). Перечень функций 
и/или нефункциональных особенностей приложения, которые не будут подвергнуты тести- 
рованию. Причины исключения той или ИНОЙ области из списка тестируемых могут быть 
самыми различными — OT предельно НИЗКОЙ их важности для заказчика до нехватки вре- 
мени или иных ресурсов. Этот перечень составляется, чтобы у проектной команды и иных 
заинтересованных лиц было чёткое единое понимание, что тестирование таких-то особен- 
ностей приложения не запланировано — такой подход позволяет исключить появление 
ложных ожиданий и неприятных сюрпризов. 

• Тестовая стратегия (test зїгаїеру?50) и подходы (test approach331). Описание процесса тести- 
рования C ТОЧКИ зрения применяемых методов, подходов, видов тестирования, технологий, 
инструментальных средств ит.д. 

• Критерии (criteria). Этот раздел включает следующие подразделы: 


° Приёмочные критерии, критерии качества (acceptance сгіїегіа332) — любые объектив- 
ные показатели качества, которым разрабатываемый продукт должен соответствовать 
с точки зрения заказчика или пользователя, чтобы считаться готовым к эксплуатации. 

° Критерии начала тестирования (entry сгиена333) — перечень условий, при выполне- 
нии которых команда приступает к тестированию. Наличие этого критерия страхует 
команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт 
ожидаемой пользы. 

° Критерии приостановки тестирования (suspension сгіќегіа334) — перечень условий, 
при выполнении которых тестирование приостанавливается. Наличие этого критерия 
также страхует команду от бессмысленной траты усилий в условиях, когда тестирова- 
ние не принесёт ожидаемой пользы. 

° Критерии возобновления тестирования (resumption criteria?35) — перечень условий, 
при выполнении которых тестирование возобновляется (как правило, после приоста- 
новки). 

° Критерии завершения тестирования (exit сгїїегїа256) — перечень условий, при выпол- 
нении которых тестирование завершается. Наличие этого критерия страхует команду 
как от преждевременного прекращения тестирования, так и от продолжения тестиро- 
вания в условиях, когда оно уже перестаёт приносить ощутимый эффект. 

e Ресурсы (resources). В данном разделе тест-плана перечисляются все необходимые для 
успешной реализации стратегии тестирования ресурсы, которые в общем случае можно 
разделить на: 


330 Test strategy. А high-level description of the test levels to be performed апа the testing within those levels (group of test 
activities that are organized and managed together, e.g. component test, integration test, system test and acceptance test) for an 
organization or program (one or more projects). [ISTQB Glossary] 

331 Test approach. The implementation of the test strategy for a specific project. It typically includes the decisions made that 
follow based on the (test) projects goal and the risk assessment carried out, starting points regarding the test process, the test 
design techniques to be applied, exit criteria and test types to be performed. [ISTQB Glossary] 

332 Acceptance criteria. The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, 
or other authorized entity. [ISTQB Glossary] 

333 Entry criteria. The set of generic and specific conditions for permitting a process to go forward with a defined task, 
e.g. test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared 
to the effort needed to remove the failed entry criteria. [ISTQB Glossary] 

334 Suspension criteria. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. 
[ISTQB Glossary] 

335 Resumption criteria. The criteria used to restart all or a portion of the testing activities that were suspended previously. 
[ISTQB Glossary] 

336 Fxit criteria. The set of generic and specific conditions, agreed upon with the stakeholders for permitting a process to 
be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still 
outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop 
testing. [ISTQB Glossary] 
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° программные ресурсы (какое ПО необходимо команде тестировщиков, сколько копий 
и скакими лицензиями (если речь идёт о коммерческом ПО)); 

° аппаратные ресурсы (какое аппаратное обеспечение, в каком количестве и к какому 
моменту необходимо команде тестировщиков); 

° человеческие ресурсы (сколько специалистов какого уровня и со знаниями в каких об- 
ластях должно подключиться к команде тестировщиков в тот или иной момент вре- 
мени); 

° временные ресурсы (сколько по времени займёт выполнение тех или иных работ); 

° финансовые ресурсы (в какую сумму обойдётся использование имеющихся или полу- 
чение недостающих ресурсов, перечисленных в предыдущих пунктах этого списка); 
во многих компаниях финансовые ресурсы могут быть представлены отдельным доку- 
ментом, т.к. являются конфиденциальной информацией. 


e Расписание (test schedule?37). Фактически это календарь, в котором указано, что и к Ka- 
кому моменту должно быть сделано. Особое внимание уделяется т.н. «ключевым точкам» 
(milestones), к моменту наступления которых должен быть получен некий значимый ощути- 
мый результат. 

• Роли и ответственность (roles and responsibility). Перечень необходимых ролей (например, 
«ведущий тестировщик», «эксперт по оптимизации производительности») и область ответ- 
ственности специалистов, выполняющих эти роли. 

e Оценка рисков (risk evaluation). Перечень рисков, которые с высокой вероятностью могут 
возникнуть в процессе работы над проектом. По каждому риску даётся оценка представляе- 
мой им угрозы и приводятся варианты выхода из ситуации. 

• Документация (documentation). Перечень используемой тестовой документации с указани- 
ем, кто и когда должен её готовить и кому передавать. 

• Метрики (metrics338). Числовые характеристики показателей качества, способы их оценки, 
формулы и т. д. На этот раздел, как правило, формируется множество ссылок из других раз- 
делов тест-плана. 


Метрики в тестировании являются настолько важными, что о них мы поговорим отдельно. 
Итак. 


Метрика (metric?38) — числовая характеристика показателя качества. Может включать 
описание способов оценки и анализа результата. 


Сначала поясним важность метрик на тривиальном примере. Представьте, что заказчик ин- 
тересуется текущим положением дел и просит вас кратко охарактеризовать ситуацию с тести- 
рованием на проекте. Общие слова в стиле «всё хорошо», «всё плохо», «нормально» и тому по- 
добное его, конечно, не устроят, т.к. они предельно субъективны и могут быть крайне далеки от 
реальности. И совсем иначе выглядит ответ наподобие такого: «Реализовано 79 % требований 
(вт.ч. 94 % важных), за последние три спринта тестовое покрытие выросло с 63 % до 71 %, а об- 
щий показатель прохождения тест-кейсов вырос с 85 % до 89 %. Иными словами, мы полностью 
укладываемся в план по всем ключевым показателям, а по разработке даже идём с небольшим 
опережением». 

Чтобы оперировать всеми этими числами (а они нужны не только для отчётности, но и для 
организации работы проектной команды), их нужно как-то вычислить. Именно это и позволяют 
сделать метрики. Затем вычисленные значения можно использовать для: 


337 Test schedule. А list of activities, tasks ог events of the test process, identifying their intended start and finish dates 
and/or times, and interdependencies. [ISTQB Glossary] 


338 Metric. A measurement scale and the method used for measurement. [ISTQB Glossary] 


Раздел 2: ОСНОВНЫЕ ЗНАНИЯ И УМЕНИЯ ШШШ 


212 


• принятия решений о начале, приостановке, возобновлении или прекращении тестирования 
(см. выше раздел «Критерии» тест-плана); 

• определения степени соответствия продукта заявленным критериям качества; 

• определения степени отклонения фактического развития проекта от плана; 

• выявления «узких мест», потенциальных рисков и иных проблем; 

» оценки результативности принятых управленческих решений; 

• подготовки объективной информативной отчётности; 

e ИТ.Д. 


Метрики могут быть как прямыми (не требуют вычислений), так и расчётными (вычисляются 
по формуле). Типичные примеры прямых метрик — количество разработанных тест-кейсов, ко- 
личество найденных дефектов и т.д. В расчётных метриках могут использоваться как совершен- 
но тривиальные, так и довольно сложные формулы (см. таблицу 2.6.1). 


Таблица 2.6.1 — Примеры расчётных метрик 


Простая расчётная метрика 


Сложная расчётная метрика 


$Р Т5иссе$5 
Т = тТоа1 


- 100%, где 
TS? — процентный показатель успешно- 
го прохождения тест-кейсов, 


Т?Ч©©9$5 — количество успешно выпол- 


ненных тест-кейсов, 


Т79%1 _ общее количество выполнен- 


ных тест-кейсов. 


Минимальные границы значений: 


• Начальная фаза проекта: 10 %. 
e Основная фаза проекта: 40 %. 
• Финальная фаза проекта: 85 %. 


R 
MaxLevel (Тере) “Гете! 


SC = 
T = Level 


где 
BLevel ›ГД 

5с v 
T = интегральная метрика прохождения тест-кеи- 


сов во взаимосвязи с требованиями и дефектами, 


TLevel — степень важности тест-кейса, 
I — количество выполнений тест-кейса, 
Керер — степень важности требования, проверяе- 


мого тест-кейсом, 


Breve — количество дефектов, обнаруженных 
тест-кейсом. 


Способ анализа: 


° Идеальным состоянием является непрерывный 
рост значения Т°©. 

• В случае отрицательной динамики уменьшение 
значения Т на 15 % и более за последние три 
спринта может трактоваться как недопустимое и 
являться достаточным поводом для приостановки 


тестирования. 


В тестировании существует большое количество общепринятых метрик, многие из которых 
могут быть собраны автоматически с использованием инструментальных средств управления 


проектами. Например?333: 


• процентное отношение (не) выполненных тест-кейсов ко всем имеющимся; 
• процентный показатель успешного прохождения тест-кейсов (см. «Простая расчётная MeT- 


рика» в таблице 2.6.1); 


• процентный показатель заблокированных тест-кейсов; 


• плотность распределения дефектов; 


• эффективность устранения дефектов; 


e распределение дефектов по важности и срочности; 


• ИТ.Д. 


339 «Important Software Test Metrics and Measurements — Explained with Examples and Graphs» [http://www. 
softwaretestinghelp.com/software-test-metrics-and-measurements/] 
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Как правило, при формировании отчётности нас будет интересовать не только текущее зна- 
чение метрики, но и её динамика во времени, которую очень удобно изображать графически 
(что тоже могут выполнять автоматически многие средства управления проектами). 

Некоторые метрики могут вычисляться на основе данных о расписании, например метрика 
«сдвига расписания»: 


DaysToDeadline 


ScheduleSlippage = — 1, rge 


NeededDays 


ScheduleSlippage — значение сдвига расписания, 

DaysToDeadline — количество дней до запланированного завершения работы, 
NeededDays — количество дней, необходимое для завершения работы. 
Значение ScheduleSlippage не должно становиться отрицательным. 


Таким образом, мы видим, что метрики являются мощнейшим средством сбора и анализа ин- 
формации. И вместе с тем здесь кроется опасность: ни при каких условиях нельзя допускать 
ситуации «метрик ради метрик», когда инструментальное средство собирает уйму данных, вы- 
числяет множество чисел и строит десятки графиков, но... никто не понимает, как их тракто- 
вать. Обратите внимание, что к обеим метрикам в таблице 2.6.1 и к только что рассмотренной 


метрике ScheduleSlippage прилагается краткое руководство по их трактовке. И чем сложнее 
и уникальнее метрика, тем более подробное руководство необходимо для её эффективного при- 
менения. 


И, наконец, стоит упомянуть про так называемые «метрики покрытия», т.к. они очень часто 
упоминаются в различной литературе. 
»\ Покрытие (соуегазе340) — процентное выражение степени, в которой исследуемый 
элемент (coverage пет 341) затронут соответствующим набором тест-кейсов. 


Самыми простыми представителями метрик покрытия можно считать: 


e Метрику покрытия требований (требование считается «покрытым», если на него ссылается 
хотя бы один тест-кейс): 


si iet рСотетеа 
р5йтыесСотетаде — ' 100%, где 


pTotal 


р5їтр!еСотетаде 5 
— метрика покрытия требований, 


RCovered L количество требований, покрытых хотя бы одним тест-кейсом, 


pTotal о 
— общее количество требований. 


e Метрику плотности покрытия требований (учитывается, сколько тест-кейсов ссылается на 
несколько требований): 


РепзиуСотетаде — УТ; i 0, 
R — ТТоѓаї.рТоѓаї 100 %, где 


pPersityCoverage плотность покрытия требований, 


Т; — количество тест-кейсов, покрывающих i-e требование, 


ТТоѓа! р 
— общее количество тест-кейсов, 
pTotal р 
— общее количество требований. 
340 


Coverage, Test coverage. The degree, expressed as а percentage, to which а specified coverage item has been exercised 
by a test suite. [ISTQB Glossary] 

341 Coverage item. An entity or property used as a basis for test coverage, e.g. equivalence partitions or code statements. 
[ISTQB Glossary] 
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e Метрику покрытия классов эквивалентности (анализируется, сколько классов эквивалент- 
ности затронуто тест-кейсами). 


Covered 
Е Сотетаде _Е 100% 
— pgTotal о, где 
Е Coverage = метрика покрытия классов эквивалентности, 
ЕСотетеа 


— количество классов эквивалентности, покрытых хотя бы одним тест-кейсом, 


ЕТоѓаї 
= общее количество классов эквивалентности. 


e Метрику покрытия граничных условий (анализируется, сколько значений из группы rpa- 
ничных условий затронуто тест-кейсами). 
вСотетеа 


Coverage — Н 0, 
В — pTotal 100 %, где 
ВСотетаде М 
— метрика покрытия граничных условий, 
ВСотетеа 


— количество граничных условий, покрытых хотя бы одним тест-кейсом, 


pTotal ä 
— общее количество граничных условий. 


e Метрики покрытия кода модульными тест-кейсами. Таких метрик очень много, но вся их 
суть сводится к выявлению некоей характеристики кода (количество строк, ветвей, путей, 
условий и т.д.) и определению, какой процент представителей этой характеристики покрыт 
тест-кейсами. 


полутора десяткам таковых. Вы можете найти эти определения, выполнив в файле 


© Метрик покрытия настолько много, что даже в 15ТОВ-глоссарии дано определение 
ІЅТОВ-глоссария поиск по слову «coverage». 


На этом мы завершаем теоретическое рассмотрение планирования и переходим к примеру — 
учебному тест-плану для нашего приложения «Конвертер файлов{5}». Напомним, что приложе- 
ние является предельно простым, потому и тест-план будет очень маленьким (однако, обратите 
внимание, сколь значительную его часть будет занимать раздел метрик). 


ПРИМЕР ТЕСТ-ПЛАНА 


Для того чтобы заполнить некоторые части тест-плана, нам придётся сделать допущения о 
составе проектной команды и времени, отведённом на разработку проекта. Поскольку данный 
тест-план находится внутри текста книги, у него нет таких типичных частей, как заглавная стра- 
ница, содержание и т. п. Итак. 


Цель 

Корректное автоматическое преобразование содержимого документов к единой кодировке с 
производительностью, значительно превышающей производительность человека при выполне- 
нии аналогичной задачи. 


Области, подвергаемые тестированию 
(См. соответствующие разделы требований.) 


e ПТ-1.*: дымовой тест. 

• IIT-2.*: дымовой тест, тест критического пути. 
• ПТ-3.*: тест критического пути. 

e БП-1.*: дымовой тест, тест критического пути. 
e АК-1.*: дымовой тест, тест критического пути. 
e О-4: дымовой тест. 


шиши 2.6. ОЦЕНКА ТРУДОЗАТРАТ, ПЛАНИРОВАНИЕ И ОТЧЕТНОСТЬ 215 


e О-5: дымовой тест. 
• ДС-*: дымовой тест, тест критического пути. 


Области, не подвергаемые тестированию 

e СХ-1: приложение разрабатывается как консольное. 

e СХ-2, О-1, О-2: приложение разрабатывается на РНР указанной версии. 

e АК-1: заявленная характеристика находится вблизи нижней границы производительности 
операций, характерных для разрабатываемого приложения. 

e О-3: не требует реализации. 

e О-6: не требует реализации. 


Тестовая стратегия и подходы 


Общий подход. 

Специфика работы приложения состоит в однократном конфигурировании опытным специа- 
листом и дальнейшем использовании конечными пользователями, для которых доступна только 
одна операция — размещение файла в каталоге-приёмнике. Потому вопросы удобства использо- 
вания, безопасности и т.п. не исследуются в процессе тестирования. 


Уровни функционального тестирования: 


• Дымовой тест: автоматизированный с использованием командных файлов ОС Windows и 
Linux. 

» Тест критического пути: выполняется вручную. 

• Расширенный тест не производится, т.к. для данного приложения вероятность обнаруже- 
ния дефектов на этом уровне пренебрежимо мала. 


В силу кроссфункциональности команды значительного вклада в повышение качества можно 
ожидать от аудита кода, совмещённого с ручным тестированием по методу белого ящика. Авто- 
матизация тестирования кода не будет применяться в силу крайне ограниченного времени. 

Критерии 

• Приёмочные критерии: успешное прохождение 100 % тест-кейсов уровня дымового тести- 
рования и 90 % тест-кейсов уровня критического пути (см. метрику «Успешное прохожде- 
ние тест-кейсов») при условии устранения 100 % дефектов критической и высокой важности 
(см. метрику «Общее устранение дефектов»). Итоговое покрытие требований тест-кейсами 
(см. метрику «Покрытие требований тест-кейсами») должно составлять не менее 80 %. 

• Критерии начала тестирования: выход билда. 

• Критерии приостановки тестирования: переход к тесту критического пути допустим толь- 
ко при успешном прохождении 100 % тест-кейсов дымового теста (см. метрику «Успешное 
прохождение тест-кейсов»); тестирование может быть приостановлено в случае, если при 
выполнении не менее 25 % запланированных тест-кейсов более 50 % из них завершились 
обнаружением дефекта (см. метрику «Стоп-фактор»). 

• Критерии возобновления тестирования: исправление более 50 % обнаруженных на преды- 
дущей итерации дефектов (см. метрику «Текущее устранение дефектов»). 

• Критерии завершения тестирования: выполнение более 80 % запланированных на итерацию 
тест-кейсов (см. метрику «Выполнение тест-кейсов»). 


Ресурсы 


e Программные ресурсы: четыре виртуальных машины (две с ОС Windows 7 Ent x64, двес ОС 
Linux Ubuntu 14 LTS x64), две копии РНР Storm 8. 
e Аппаратные ресурсы: две стандартных рабочих станции (8GB КАМ, 17 3СН7). 
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e Финансовые ресурсы: согласно утверждённому бюджету. Дополнительные финансовые pe- 
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Человеческие ресурсы: 


° Старший разработчик с опытом тестирования (100%-я занятость на всём протяжении 
проекта). Роли на проекте: лидер команды, старший разработчик. 
° Тестировщик со знанием РНР (100%-я занятость на всём протяжении проекта). Роль на 


проекте: тестировщик. 


Временные ресурсы: одна рабочая неделя (40 часов). 


сурсы не требуются. 


Расписание 


25.05 — формирование требований. 


26.05 — разработка тест-кейсов и скриптов для автоматизированного тестирования. 


27.05-28.05 — основная фаза тестирования (выполнение тест-кейсов, написание отчётов о 


дефектах). 
29.05 — завершение тестирования и подведение итогов. 


Роли и ответственность 


e Старший разработчик: участие в формировании требований, участие в аудите кода. 


e Тестировщик: формирование тестовой документации, реализация тестирования, участие в 


аудите кода. 


Оценка рисков 


Персонал (вероятность низкая): в случае нетрудоспособности какого-либо из участников 
команды можно обратиться K представителям проекта «Каталогизатор» ДЛЯ предоставле- 
ния временной замены (договорённость с менеджером «Каталогизатора» Джоном Смитом 


достигнута). 


Время (вероятность высокая): заказчиком обозначен крайний срок сдачи 01.06, потому вре- 
мя является критическим ресурсом. Рекомендуется приложить максимум усилий к тому, 
чтобы фактически завершить проект 28.05 с тем, чтобы один день (29.05) остался в запасе. 


Иные риски: иных специфических рисков не выявлено. 


Документация 


e Тест-кейсы и отчёты о дефектах. Ответственный — тестировщик, период создания 26.05- 


e Отчёт о результатах тестирования. Ответственный — тестировщик, дата готовности 29.05. 


Требования. Ответственный — тестировщик, дата готовности 25.05. 


28.05. 


Метрики 


Успешное прохождение тест-кейсов: 
т5иссеѕ5 


ТЭР = —— . 100%, где 


Total 


ТР — процентный показатель успешного прохождения тест-кейсов, 


ТЎЧ©сё55 L количество успешно выполненных тест-кейсов, 


TT% __ общее количество выполненных тест-кейсов. 


Минимальные границы значений: 
° Начальная фаза проекта: 10%. 
° Основная фаза проекта: 40%. 
° Финальная фаза проекта: 80%. 
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e Общее устранение дефектов: 


ЕТР ТШ 

— #Level_, 0, 

"ере — pFound 100%, где 
Level 


FTP 
Dievel — процентный показатель устранения дефектов уровня важности Level за время cy- 


ществования проекта 


Closed = 
"Рүере — количество устранённых за время существования проекта дефектов уровня 
важности Level, 
рЕоита 

Level — количество обнаруженных за время существования проекта дефектов уровня важ- 


ности Level. 


Минимальные границы значений: 


Важность дефекта 
Низкая Средняя Высокая Критическая 
А Начальная 10% 40% 50% 80% 
а Основная 15% 50% 75% 90% 
проекта 
Финальная 20% 60% 100% 100% 


° Текущее устранение дефектов: 
ЕСР ТШ 
— Гете 
"ете — pFound Е 100%, где 
Level 
DECE 5 
Level — процентный показатель устранения в текущем билде дефектов уровня важности 
Level, обнаруженных в предыдущем билде, 


р Closed 


Level — количество устранённых в текущем билде дефектов уровня важности Level, 
Dievel — количество обнаруженных в предыдущем билде дефектов уровня важности Level. 
Минимальные границы значений: 

Важность дефекта 
Низкая Средняя Высокая Критическая 
Начальная 60% 60% 60% 60% 
4 Основная 65% 70% 85% 90% 
Финальная 70% 80% 95% 100% 


e Стоп-фактор: 


_ к > 25% && Т5Р < 50% 


‚Где 
No, ТЕ < 25% || TSP > 50% °" 


S — решение о приостановке тестирования, 
TE текущее значение метрики TE, 


Т? — текущее значение метрики Т. 


• Выполнение тест-кейсов: 


T тЕхесшеа 


ТЕ = * 100%, где 


тРіатпеа 
ТЕ — процентный показатель выполнения тест-кейсов, 


Executed количество выполненных тест-кейсов, 


тР!аттеа v 
— количество тест-кеисов, запланированных к выполнению. 
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Уровни (границы): 
° Минимальный уровень: 80 %. 
° Желаемый уровень: 95-100 %. 


• Покрытие требований тест-кейсами: 


рСотетеа 


RE = * 100%, где 


pTotal 


КС — процентный показатель покрытия требования тест-кейсами, 


RCovered L количество покрытых тест-кейсами требований, 


ВТО m 
— общее количество требований. 


Минимальные границы значений: 


° Начальная фаза проекта: 40 %. 
° Основная фаза проекта: 60 %. 
° Финальная фаза проекта: 80 % (рекомендуется 90 % и более). 
72 Задание 2.6.а: поищите в Интернете более развёрнутые примеры тест-планов. Они пе- 
Ө риодически появляются, но и столь же быстро удаляются, т. к. настоящие (не учебные) 
тест-планы, как правило, являются конфиденциальной информацией. 


На этом мы завершаем обсуждение планирования и переходим к отчётности, которая завер- 
шает цикл тестирования. 


ОТЧЁТ О РЕЗУЛЬТАТАХ ТЕСТИРОВАНИЯ 


= Отчёт о результатах тестирования (test progress герог 42, test summary герогіЗ43) — 

О документ, обобщающий результаты работ по тестированию и содержащий информа- 

цию, достаточную для соотнесения текущей ситуации с тест-планом и принятия необ- 
ходимых управленческих решений. 


К низкоуровневым задачам отчётности в тестировании относятся: 


• оценка объёма и качества выполненных работ; 

e сравнение текущего прогресса с тест-планом (в том числе с помощью анализа значений 
метрик); 

• описание имеющихся сложностей и формирование рекомендаций по их устранению; 

• предоставление лицам, заинтересованным в проекте, полной и объективной информации о 
текущем состоянии качества проекта, выраженной в конкретных фактах и числах. 


Как и любой другой документ, отчёт о результатах тестирования может быть качественным 
или обладать недостатками. Качественный отчёт о результатах тестирования обладает многими 
свойствами качественных требований{44}, а также расширяет их набор следующими пунктами: 


e Информативность (в идеале после прочтения отчёта не должно оставаться никаких откры- 
тых вопросов о том, что происходит с проектом в контексте качества). 

e Точность и объективность (ни при каких условиях в отчёте не допускается искажение þak- 
тов, а личные мнения должны быть подкреплены твёрдыми обоснованиями). 


342 Test progress report. А document summarizing testing activities and results, produced at regular intervals, to report 
progress of testing activities against a baseline (such as the original test plan) and to communicate risks and alternatives requiring 
a decision to management. [ISTQB Glossary] 


343 Test summary report. A document summarizing testing activities and results. It also contains an evaluation of the 
corresponding test items against exit criteria. [ISTQB Glossary] 
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Отчёт о результатах тестирования создаётся по заранее оговорённому расписанию (завися- 
щему от модели управления проектом) при участии большинства представителей проектной ко- 
манды, задействованных в обеспечении качества. Большое количество фактических данных для 
отчёта может быть легко извлечено в удобной форме из системы управления проектом. Ответ- 
ственным за создание отчёта, как правило, является ведущий тестировщик («тест-лид»). При не- 
обходимости отчёт может обсуждаться на небольших собраниях. 

Отчёт о результатах тестирования в первую очередь нужен следующим лицам: 


• менеджеру проекта — как источник информации о текущей ситуации и основа для приня- 
тия управленческих решений; 

e руководителю команды разработчиков («дев-лиду») — как дополнительный объективный 
взгляд на происходящее на проекте; 

e руководителю команды тестировщиков («тест-лиду») — как способ структурировать соб- 
ственные мысли и собрать необходимый материал для обращения к менеджеру проекта по 
насущным вопросам, если в этом есть необходимость; 

e заказчику — как наиболее объективный источник информации о том, что происходит на 
проекте, за который он платит свои деньги. 


В общем случае отчёт о результатах тестирования включает следующие разделы (примеры их 

наполнения будут показаны далее, потому здесь — только перечисление). 
N Важно! Если по поводу тест-плана в сообществе тестировщиков есть более-менее усто- 
@ явшееся мнение, то формы отчётов о результатах тестирования исчисляются десят- 
ками (особенно, если отчёт привязан к некоторому отдельному виду тестирования). 


Здесь приведён наиболее универсальный вариант, который может быть адаптирован 
под конкретные нужды. 


e Краткое описание (summary). В предельно краткой форме отражает основные достижения, 
проблемы, выводы и рекомендации. В идеальном случае прочтения краткого описания мо- 
жет быть достаточно для формирования полноценного представления о происходящем, что 
избавит от необходимости читать весь отчёт (это важно, т.к. отчёт о результатах тестирова- 
ния может попадать в руки очень занятым людям). 


“= Важно! Различайте краткое описание отчёта о результатах тестирования и краткое 
@ описание отчёта о дефекте!176}! При одинаковом названии они создаются по разным 


принципам и содержат разную информацию! 


• Команда тестировщиков (test team). Список участников проектной команды, задейство- 
ванных в обеспечении качества, с указанием их должностей и ролей в подотчётный период. 

• Описание процесса тестирования (testing process description). Последовательное описание 
того, какие работы были выполнены за подотчётный период. 

e Расписание (timetable). Детализированное расписание работы команды тестировщиков 
и/или личные расписания участников команды. 

e Статистика по новым дефектам (new defects statistics). Таблица, в которой представлены 
данные по обнаруженным за подотчётный период дефектам (с классификацией по стадии 
жизненного цикла и важности). 

e Список новых дефектов (new defects list). Список обнаруженных за подотчётный период 
дефектов с их краткими описаниями и важностью. 

e Статистика по всем дефектам (overall defects statistics). Таблица, в которой представлены 
данные по обнаруженным за всё время существования проекта дефектам (с классифика- 
цией по стадии жизненного цикла и важности). Как правило, в этот же раздел добавляется 
график, отражающий такие статистические данные. 
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• Рекомендации (recommendations). Обоснованные выводы и рекомендации по принятию тех 
или иных управленческих решений (изменению тест-плана, запросу или освобождению ре- 
сурсов ит. д.) Здесь этой информации можно отвести больше места, чем в кратком описании 
(summary), сделав акцент именно на том, что и почему рекомендуется сделать в имеющейся 
ситуации. 

• Приложения (appendixes). Фактические данные (как правило, значения метрик и графиче- 
ское представление их изменения во времени). 


ЛОГИКА ПОСТРОЕНИЯ ОТЧЁТА О РЕЗУЛЬТАТАХ ТЕСТИРОВАНИЯ 


Для того чтобы отчёт о результатах тестирования был действительно полезным, при его 
создании следует постоянно помнить об универсальной логике отчётности (см. рисунок 2.6.Б), 
особенно актуальной для таких разделов отчёта о результатах тестирования, как краткое описа- 
ние (summary) и рекомендации (recommendations): 


• Выводы строятся на основе целей (которые были отражены в плане). 
• Выводы дополняются рекомендациями. 

• Как выводы, так и рекомендации строго обосновываются. 

e Обоснование опирается на объективные факты. 


На основе 


целей < 
Выводы 


Рекомендации 


Обоснование 


Фактический материал 


Рисунок 2.6.6 — Универсальная логика отчётности 


Выводы должны быть: 


e Краткими. Сравните: 


Плохо 


Хорошо 


1.17. Как показал глубокий анализ протоколов 
о выполнении тестирования, можно сделать 
достаточно уверенные выводы о том, что ос- 
новная часть функций, отмеченных заказчи- 
ком как наиболее важные, функционирует в 
рамках допустимых отклонений от согласован- 
ных на последнем обсуждении с заказчиком 
метрик качества. 


1.11. Базовая функциональность полностью 
работоспособна (см. 2.1-2.2). 


1.23. Существуют некритические проблемы 
с детализацией сообщений в файле журнала 
(см. 2.3-2.4). 


1.28. Тестирование приложения под ОС Linux 
не удалось провести из-за недоступности сер- 
вера $В-85 (см. 2.5). 
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e Информативными. Сравните: 


Плохо 


Хорошо 


1.8. Результаты обработки файлов с множе- 
ственными кодировками, представленными в 
сопоставимых пропорциях, оставляют желать 
лучшего. 

1.9. Приложение не запускается при некото- 
рых значениях параметров командной строки. 
1.10. Непонятно, что происходит с анализом 
изменения содержимого входного каталога. 


1.8. Обнаружены серьёзные проблемы 
с библиотекой распознавания кодировок 
(см. ВВ 834). 


1.9. Нарушена функциональность анали- 
за параметров командной строки (см. ВК 745, 
ВК 877, ВК 878). 

1.10. Выявлена нестабильность в работе моду- 
ля «Сканер», проводятся дополнительные ис- 
следования. 


• Полезными для читающего отчёт. Сравните: 


Плохо 


Хорошо 


1.18. Некоторые тесты прошли на удивление 
хорошо. 

1.19. В процессе тестирования мы не испыты- 
вали сложности с настройкой среды автомати- 
зации. 

1.20. По сравнению с результатами, которые 
были получены вчера, ситуация немного улуч- 
шилась. 

1.21. С качеством по-прежнему есть некото- 
рые проблемы. 


1.22. Часть команды была в отпуске, но мы всё 
равно справились. 


Представленного в колонке «Плохо» просто 
не должно быть в отчёте! 


Рекомендации должны быть: 


e Краткими. Да, мы снова говорим о краткости, т.к. её отсутствием страдает слишком боль- 


шое количество документов. Сравните: 


Плохо 


Хорошо 


2.98. Мы рекомендуем рассмотреть возмож- 
ные варианты исправления данной ситуации в 
контексте поиска оптимального решения при 
условии минимизации усилий разработчиков 
и максимального повышения соответствия 
приложения заявленным критериям качества, 
а именно: исследовать возможность замены 
некоторых библиотек их более качественными 
аналогами. 


2.98. Необходимо изменить способ определе- 
НИЯ кодировки текста в документе. Возможные 
решения: 


e [сложно, надёжно, но очень долго] написать 
собственное решение; 

• [требует дополнительного исследования и 
согласования] заменить проблемную биб- 
лиотеку «сЯК п г содіпо» аналогом (воз- 
можно, коммерческим). 
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» Реально выполнимыми. Сравните: 


Плохо 


Хорошо 


2.107. Использовать механизм обработки слов, 
аналогичный используемому в Google. 

2.304. Не загружать в оперативную память ин- 
формацию о файлах во входном каталоге. 
2.402. Полностью переписать проект без ис- 
пользования внешних библиотек. 


2.107. Реализовать алгоритм приведения 
слов русского языка к именительному падежу 
(см. описание по ссылке ...) 


2.304. Увеличить размер доступной скрипту 
оперативной памяти на 40-50% (в идеале — 
до 512 МБ). 


2.402. Заменить собственными решениями 
функции анализа содержимого каталога и па- 
раметров файлов библиотеки «cflk_n_r_flstm». 


° Дающими как понимание того, что надо сделать, так и некоторое пространство для приня- 


тия собственных решений. Сравните: 


Плохо 


Хорошо 


2.212. Рекомендуем поискать варианты реше- 
ния этого вопроса. 


2.245. Использовать только дисковую сорти- 
ровку. 
2.278. Исключить возможность передачи не- 


корректных имён файла журнала через пара- 
метр командной строки. 


2.212. Возможные варианты решения: 


а)... 
6) [рекомендуем!]... 


в)... 


2.245. Добавить функциональность определе- 
ния оптимального метода сортировки в зави- 
симости от количества доступной оператив- 
ной памяти. 


2.278. Добавить фильтрацию имени файла 
журнала, получаемого через параметр команд- 
ной строки, с помощью регулярного выра- 
жения. 


Обоснование выводов и рекомендаций — промежуточное звено между предельно сжатыми 
результатами анализа и огромным количеством фактических данных. Оно даёт ответы на вопро- 


сы наподобие: 
• «Почему мы так считаем?» 
• «Неужели это так?!» 
• «Где взять дополнительные данные?» 
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Сравните: 
Плохо Хорошо 

4.107. Покрытие требований тест-кейсами до- | 4.107. Покрытие требований тест-кейсами вы- 
статочно. шло на достаточный уровень (значение КС co- 

о 0 0, 
4.304. Необходимо больше усилий направить | СТавило 63 % при заявленном минимуме 60 % 
на регрессионное тестирование. для текущей стадии проекта). 
4.402. От сокращения сроков разработки сто- | 4.304. Необходимо больше усилий напра- 
ит отказаться. вить на регрессионное тестирование, т. к. две 


предыдущих итерации выявили 21 дефект 
высокой важности (см. список в 5.43) в функ- 
циональности, в которой ранее не обнаружи- 
валось проблем. 


4.402. От сокращения сроков разработки сто- 
ит отказаться, т.к. текущее опережение гра- 
фика на 30 человеко-часов может быть легко 
поглощено на стадии реализации требований 
R84.* и R89.*. 


Фактический материал содержит самые разнообразные данные, полученные в процессе Tec- 
тирования. Сюда могут относиться отчёты о дефектах, журналы работы средств автоматизации, 
созданные различными приложениями наборы файлов и т.д. Как правило, к отчёту о результа- 
тах тестирования прилагаются лишь сокращённые агрегированные выборки подобных данных 
(если это возможно), а также приводятся ссылки на соответствующие документы, разделы систе- 
мы управления проектом, пути в хранилище данных ит.д. 


На этом мы завершаем теоретическое рассмотрение отчётности и переходим к примеру — 
учебному отчёту о результатах тестирования нашего приложения «Конвертер файлов»{59}. Ha- 
помним, что приложение является предельно простым, потому и отчёт о результатах тестирова- 
ния будет очень маленьким. 


ПРИМЕР ОТЧЁТА О РЕЗУЛЬТАТАХ ТЕСТИРОВАНИЯ 


Для того, чтобы заполнить некоторые части отчёта, нам придётся сделать допущения о теку- 
щем моменте развития проекта и сложившейся ситуации с качеством. Поскольку данный от- 
чёт находится внутри текста книги, у него нет таких типичных частей, как обложка, содержа- 
ние ит. п. 

Итак. 


Краткое описание. За период 26-28 мая было выпущено четыре билда, на последнем из кото- 
рых успешно прошло 100 % тест-кейсов дымового тестирования и 76 % тест-кейсов тестирования 
критического пути. 98 % требований высокой важности реализовано корректно. Метрики каче- 
ства находятся в зелёной зоне, потому есть все основания рассчитывать на завершение проекта 
в срок (на текущий момент реальный прогресс в точности соответствует плану). На следующую 
итерацию (29 мая) запланировано выполнение оставшихся низкоприоритетных тест-кейсов. 


Команда тестировщиков. 


Имя Должность Роль 


Джо Блэк Тестировщик Ответственный за обеспечение качества 


Джим Уайт Старший разработчик |Ответственный за парное тестирование и аудит кода 
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Описание процесса тестирования. Каждый из четырёх выпущенных за подотчётный период 
билдов (3-6) был протестирован под ОС Windows 7 Ent x64 и ОС Linux Ubuntu 14 LTS x64 в среде 
исполнения РНР 5.6.0. Дымовое тестирование (см. http://projects/FC/Testing/SmokeTest) выполня- 
лось с использованием автоматизации на основе командных файлов (см. \\PROJECTS\FC\Testing\ 
Aut\Scripts). Тестирование критического пути (см. http://projects/FC/Testing/CriticalPathTest) вы- 
полнялось вручную. Регрессионное тестирование показало высокую стабильность функцио- 
нальности (обнаружен только один дефект с важностью «средняя»), а повторное тестирование 
показало ощутимый прирост качества (исправлено 83 % обнаруженных ранее дефектов). 


Расписание. 
Имя Дата Деятельность Продолжительность, ч 

Джо Блэк 27.05.2015 |Разработка тест-кейсов 2 
Джо Блэк 27.05.2015 |Парное тестирование 2 
Джо Блэк 27.05.2015 | Автоматизация дымового тестирования 1 
Джо Блэк 27.05.2015 |Написание отчётов о дефектах 2 
Джим Уайт |27.05.2015 | Аудит кода 1 
Джим Уайт |27.05.2015 |Парное тестирование 2 
Джо Блэк 28.05.2015 |Разработка тест-кейсов 3 
Джо Блэк 28.05.2015 |Парное тестирование 1 
Джо Блэк 28.05.2015 |Написание отчётов о дефектах 2 
E 28.05.2015 о отчёта о результатах тестиро- 1 
Джим Уайт |28.05.2015 | Аудит кода 1 
Джим Уайт |27.05.2015 |Парное тестирование 1 

Статистика по новым дефектам. 

Важность 
Статус Количество Низкая Средняя Высокая Критическая 

Найдено 23 2 12 7 2 
Исправлено 17 0 9 6 2 
Проверено 13 0 5 6 2 
Открыто заново 1 0 0 1 0 
Отклонено 3 0 2 1 0 

Список новых дефектов. 
Идентификатор Важность Описание 
ВЕ 21 Высокая Е ты не различает файлы и симоволические ссыл- 
ВК 22 Критическая | Приложение игнорирует файлы .md во входном каталоге. 


И так далее — описание всех 23 найденных дефектов. 
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Статистика по всем дефектам. 


Важность 
Статус Количество Низкая Средняя Высокая Критическая 
Найдено 34 5 18 8 3 
Исправлено 25 3 12 7 3 
Проверено 17 0 7 7 3 
Открыто заново 1 0 1 0 
Отклонено 4 0 3 1 0 
Статистика по всем дефектам 
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тах тестирования. Они периодически появляются, HO и столь же быстро удаляются, 
т.к. настоящие (не учебные) отчёты, как правило, являются конфиденциальной ин- 
формацией. 


© Задание 2.6.Ъ: поищите в Интернете более развёрнутые примеры отчётов о результа- 
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2.6.3. ОЦЕНКА ТРУДОЗАТРАТ mamm 


В завершение данной главы мы снова возвращаемся к планированию, но уже куда более про- 
стому — к оценке трудозатрат. 


A Трудозатраты (man-hours?44) — количество рабочего времени, необходимого для вы- 
полнения работы (выражается в человеко-часах). 


Каждый раз, когда вы получаете задание или выдаёте кому-то задание, явно или неявно воз- 
никают вопросы наподобие следующих: 


e Как много времени понадобится на выполнение работы? 

e Когда всё будет готово? 

e Можно ли гарантированно выполнить работу к такому-то сроку? 

• Каковы наиболее оптимистичный и пессимистичный прогнозы по времени? 


Рассмотрим несколько соображений относительно того, как производится оценка трудозатрат. 


Любая оценка лучше её отсутствия. Даже если область предстоящей работы для вас совер- 
шенно нова, даже если вы ошибётесь в своей оценке на порядок, вы как минимум получите опыт, 
который сможете использовать в будущем при возникновении подобного рода задач. 


Оптимизм губителен. Как правило, люди склонны недооценивать сложность незнакомых за- 
дач, что приводит кзанижению оценки трудозатрат. 

Но даже при достаточно точном определении самих трудозатрат люди без опыта выполнения 
оценки склонны рассматривать предстоящую работу как некую изолированную деятельность, 
забывая о том, что на протяжении любого рабочего дня «чистую производительность труда» 
будут снижать такие факторы, как переписка по почте, участие в собраниях и обсуждениях, ре- 
шение сопутствующих технических вопросов, изучение документации и обдумывание сложных 
частей задачи, форс-мажорные обстоятельства (неотложные дела, проблемы с техникой и т. д.). 

Таким образом, обязательно стоит учитывать, что в реальности вы сможете заниматься по- 
ставленной задачей не 100 % рабочего времени, а меньше (насколько меньше — зависит от кон- 
кретной ситуации, в среднем принято считать, что на поставленную задачу из каждых восьми 
рабочих часов вы сможете потратить не более шести). Учитывая этот факт, стоит сделать соот- 
ветствующие поправки в оценке общего времени, которое понадобится на выполнение работы 
(а именно оно чаще всего интересует постановщика задачи). 


Оценка должна быть аргументирована. Это не значит, что вы всегда должны пускаться в под- 
робные пояснения, но вы должны быть готовы объяснить, почему вы считаете, что та или иная 
работа займёт именно столько времени. Во-первых, продумывая эти аргументы, вы получаете 
дополнительную возможность лучше оценить предстоящую работу и скорректировать оценку. 
Во-вторых, если ваша оценка не соответствует ожиданиям постановщика задачи, вы сможете 
отстоять свою точку зрения. 


Простой способ научиться оценивать — оценивать. В специализированной литературе 
(см. ниже небольшой список) приводится множество технологий, но первична сама привычка 
выполнять оценку предстоящей работы. В процессе выработки этой привычки вы естественным 
образом встретитесь с большинством типичных проблем и через некоторое время научитесь 
делать соответствующие поправки в оценке, даже не задумываясь. 


344 Man-hour. А unit for measuring work in industry, equal to the work done Бу опе man in one hour. [http://dictionary. 
reference.com/browse/man-hour] 
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Что оценивать? Что угодно. Сколько времени у вас уйдёт на прочтение новой книги. За сколь- 
ко времени вы доедете домой новым маршрутом. За сколько времени вы напишете курсовую или 
дипломную работу. И так далее. Не важно, что именно вы оцениваете, важно, что вы повторяете 
это раз за разом, учитывая накапливающийся опыт. 


затрат, рекомендуется ознакомиться со следующими источниками: 
• «Ше Mythical Man Month», Frederick Brooks. 


e «Controlling Software Projects», Tom De Marco. 
e «Software engineering metrics and models», Samuel Conte. 


© Если вас заинтересовал профессиональный подход к формированию оценки трудо- 


Алгоритм обучения формированию оценки: 

e Сформируйте оценку. Ранее уже было отмечено, что нет ничего страшного в том, что по- 
лученное значение может оказаться очень далёким от реальности. Для начала оно просто 
должно быть. 

• Запишите полученную оценку. Обязательно именно запишите. Это застрахует вас как MN- 
нимум от двух рисков: забыть полученное значение (особенно, если работа заняла много 
времени), соврать себе в стиле «ну, я как-то примерно так и думал». 

• Выполните работу. В отдельных случаях люди склонны подстраиваться под заранее сформи- 
рованную оценку, ускоряя или замедляя выполнение работы, — это тоже полезный навык, 
но сейчас такое поведение будет мешать. Однако если вы будете тренироваться на десятках 
и сотнях различных задач, вы физически не сможете «подстроиться» под каждую из них и 
начнёте получать реальные результаты. 

e Сверьте реальные результаты с ранее сформированной оценкой. 

e Учтите ошибки при формировании новых оценок. На этом этапе очень полезно не просто 
отметить отклонение, а подумать, что привело к его появлению. 

e Повторяйте этот алгоритм как можно чаще для самых различных областей жизни. Сейчас 
цена ваших ошибок крайне мала, а наработанный опыт от этого становится ничуть не менее 
ценным. 


Полезные идеи по формированию оценки трудозатрат: 

• Добавляйте небольшой «буфер» (по времени, бюджету или иным критическим ресурсам) 
на непредвиденные обстоятельства. Чем более дальний прогноз вы строите, тем большим 
может быть этот «буфер» — от 5-10 % до 30-40 %. Но ни в коем случае не стоит осознанно 
завышать оценку в разы. 

e Выясните свой «коэффициент искажения»: большинство людей в силу особенности своего 
мышления склонны постоянно или занижать, или завышать оценку. Многократно форми- 
руя оценку трудозатрат и сравнивая её впоследствии с реальностью, вы можете заметить 
определённую закономерность, которую вполне можно выразить числом. Например, может 
оказаться, что вы склонны занижать оценку в 1.3 раза. Попробуйте в следующий раз внести 
соответствующую поправку. 

• Принимайте во внимание не зависящие от вас обстоятельства. Например, вы точно увере- 
ны, что выполните тестирование очередного билда за М человеко-часов, вы учли все отвле- 
кающие факторы и т.д. и решили, что точно закончите к такой-то дате. А потом в реально- 
сти выпуск билда задерживается на два дня, и ваш прогноз по моменту завершения работы 
оказывается нереалистичным. 

e Задумывайтесь заранее о необходимых ресурсах. Так, например, необходимую инфраструк- 
туру можно (и нужно!) подготовить (или заказать) заранее, т.к. на подобные вспомогатель- 
ные задачи может быть потрачено много времени, к тому же основная работа часто не мо- 
жет быть начата, пока не будут завершены все приготовления. 
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° Ищите способы организовать параллельное выполнение задач. Даже если вы работаете один, 
всё равно какие-то задачи можно и нужно ВЫПОЛНЯТЬ параллельно (например, уточнение 
тест-плана, пока происходит разворачивание виртуальных машин). В случае если работа 
выполняется несколькими людьми, распараллеливание работы можно считать жизненной 
необходимостью. 

° Периодически сверяйтесь с планом, вносите корректировки В оценку и уведомляйте заин- 
тересованных ЛИЦО внесённых изменениях заблаговременно. Например, ВЫ ПОНЯЛИ (как В 
упомянутом выше примере с задержкой билда), что завершите работу как минимум на два 
дня позже. Если вы оповестите проектную команду немедленно, у ваших коллег появляется 
шанс скорректировать свои собственные планы. Если же вы в «час икс» преподнесёте сюр- 
приз о сдвигах срока на два дня, вы создадите коллегам объективную проблему. 

• Используйте инструментальные средства — от электронных календарей до возможностей 
вашей системы управления проектом: это позволит вам как минимум не держать в памяти 
кучу мелочей, а как максимум — повысит точность формируемой оценки. 


Оценка с использованием структурной декомпозиции 


2 С другими техниками формирования оценки вы можете ознакомиться в следующей 
© литературе: 


e «Essential Scrum», Kenneth Rubin. 

e «Agile Estimating and Planning», Mike Cohn. 

e «Extreme programming explained: Embrace change», Kent Beck. 

e PMBOK («Project Management Body of Knowledge»). 

• Краткий перечень основных техник с пояснениями можно посмотреть в статье 
«Software Estimation Techniques — Common Test Estimation Techniques used in 
SDLC?45», 


композиция объёмных задач на всё более и более малые подзадачи с целью упрощения 


Ө Структурная декомпозиция (work breakdown structure, WBS346) — иерархическая де- 
оценки, планирования и мониторинга выполнения работы. 


В процессе выполнения структурной декомпозиции большие задачи делятся на всё более и 
более мелкие подзадачи, что позволяет нам: 


• описать весь объём работ с точностью, достаточной для чёткого понимания сути задач, фор- 
мирования достаточно точной оценки трудозатрат и выработки показателей достижения 
результатов; 

• определить весь объём трудозатрат как сумму трудозатрат по отдельным задачам (с учётом 
необходимых поправок); 

• от интуитивного представления перейти к конкретному перечню отдельных действий, что 
упрощает построение плана, принятие решений о распараллеливании работ и т.д. 


Сейчас мы рассмотрим применение структурной декомпозиции в сочетании с упрощённым 
взглядом на оценку трудозатрат на основе требований и тест-кейсов. 


345 «Software Estimation Techniques- Common Test Estimation Techniquesusedin SDLO» [http://www.softwaretestingclass. 
com/software-estimation-techniques/] 

346 The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to 
accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the 
project. The WBS subdivides the project work into smaller, more manageable pieces of work, with each descending level of the 
WBS representing an increasingly detailed definition of the project work. The planned work contained within the lowest-level 
WBS components, which are called work packages, can be scheduled, cost esti-mated, monitored, and controlled. [PMBOK, 
3rd edition] 
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=“ С подробной теорией по данному вопросу можно ознакомиться в следующих статьях: 
© e «Test Effort Estimation Using Use Case Роз 347», Suresh Марезууагап. 
e «Test Case Point Analysis?48», Nirav Patel. 

Если абстрагироваться от научного подхода и формул, то суть такой оценки сводится K сле- 

дующим шагам: 

e декомпозиции требований ДО уровня, на котором появляется возможность создания каче- 
ственных чек-листов; 

• декомпозиции задач по тестированию каждого пункта чек-листа до уровня «тестировщиц- 
ких действий» (создание тест-кейсов, выполнение тест-кейсов, создание отчётов о дефек- 
тах ит.д.); 

• выполнению оценки с учётом собственной производительности. 


Рассмотрим этот подход на примере тестирования требования ДС-2.4{60): «При указании не- 
верного значения любого из параметров командной строки приложение должно завершить ра- 
боту, выдав сообщение об использовании (ДС-3.1), а также сообщив имя неверно указанного 
параметра, его значение и суть ошибки (см. ДС-3.2)». 


Это требование само по себе является низкоуровневым и почти не требует декомпозиции, 
но чтобы проиллюстрировать суть подхода, проведём разделение требования на составляющие: 
e Если все три параметра командной строки указаны верно, сообщение об ошибке не выда- 
ётся. 
e Если указано неверно от одного до трёх параметров, то выдаётся сообщение об использова- 
нии, имя (или имена) неверно указанного параметра и неверное значение, а также сообще- 
ние об ошибке: 


° Если неверно указан SOURCE_DIR или РЕЗТПМАТЮМ_ОГВ: «Directory not exists ог 
inaccessible». 

° Если DESTINATION_DIR находится в SOURCE_DIR: «Destination dir may not reside 
within source dir tree». 

° Если неверно указан LOG_FILE_NAME): «Wrong file name or inaccessible path». 


Создадим чек-лист и здесь же пропишем примерное количество тест-кейсов на каждый пункт 
из предположения, что мы будем проводить достаточно глубокое тестирование этого требо- 
вания: 

e Все параметры корректные {1 тест-кейс}. 

• Несуществующий/некорректный путь для: 


° SOURCEL_DIR {3 тест-кейса!; 
о DESTINATION_DIR {3 тест-кейса}. 
• Недопустимое имя файла LOG_FILE_NAME {3 тест-кейса}. 
• Значения SOURCE_DIR и DESTINATION_DIR являются корректными именами существую- 
щих каталогов, но DESTINATION_DIR находится внутри SOURCE_DIR {3 тест-кейса}. 
• Недопустимые/несуществующие имена объектов ФС указаны в более чем одном параметре 
{5 тест-кейсов}. 
• Значения SOURCE_DIR и DESTINATION_DIR не являются корректными/существующи- 
ми именами каталогов, и при этом DESTINATION_DIR находится внутри SOURCE_DIR 
{3 тест-кейса}. 


347 «Test Effort Estimation Using Use Case Points», Suresh Nageswaran [http://www.bfpug.com.br/Artigos/ UCP/ 
Nageswaran-Test_Effort_Estimation_Using ОСРра#] 

348 «Test Case Point Analysis», Nirav Patel [http://www.stickyminds.com/sites/default/files/article/file/2013/ 
XUS373692file1_0.pdf] 
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У нас получилось примерно 22 тест-кейса. Также давайте для большей показательности при- 
мера предположим, что часть тест-кейсов (например, 5) уже была создана ранее. 

Теперь сведём полученные данные в таблицу 2.6.а, где также отразим количество проходов. 
Этот показатель появляется из соображения, что некоторые тест-кейсы будут находить дефекты, 
что потребует повторного выполнения тест-кейса для верификации исправления дефекта; в не- 
которых случаях дефекты будут открыты заново, что потребует повторной верификации. Это 
относится лишь к части тест-кейсов, потому количество проходов может быть дробным, чтобы 
оценка была более точной. 

Количество проходов для тестирования новой функциональности в общем случае можно гру- 
бо оценивать так: 

Простая функциональность: 1-1.5 (не все тесты повторяются). 

Функциональность средней сложности: 2. 

Сложная функциональность: 3-5. 


Таблица 2.6.а — Оценка количества создаваемых и выполняемых тест-кейсов 


Создание Выполнение 
Количество 12 22 
Повторения (проходы) 1 1.2 
Общее количество 12 26.4 


Время на один тест-кейс 


Итоговое время 


Осталось заполнить ячейки со значениями времени, необходимого на разработку и выпол- 
нение одного тест-кейса. К сожалению, не существует никаких магических способов выяснения 
этих параметров — только накопленный опыт о вашей собственной производительности, на ко- 
торую среди прочего влияют следующие факторы (по каждому из них можно вводить коэффи- 
циенты, уточняющие оценку): 


• ваш профессионализм и опыт; 

• сложность и объёмность тест-кейсов; 

• производительность тестируемого приложения и тестового окружения; 
• вид тестирования; 

• наличие и удобство средств автоматизации; 

• стадия разработки проекта. 


Тем не менее существует простой способ получения интегральной оценки вашей собственной 
производительности, при котором влиянием этих факторов можно пренебречь: нужно измерять 
свою производительность на протяжении длительного периода времени и фиксировать, сколько 
создать и выполнить тест-кейсов вы можете в час, день, неделю, месяц и т.д. Чем больший проме- 
жуток времени будет рассмотрен, тем меньше на результаты измерений будут влиять кратковре- 
менные отвлекающие факторы, появление которых сложно предсказывать. 

Допустим, что для некоторого выдуманного тестировщика эти значения оказались следующи- 
ми — за месяц (28 рабочих дней) ему удаётся: 


» Создать 300 тест-кейсов (примерно 11 тест-кейсов в день, или 1.4 в час). 
e Выполнить 1000 тест-кейсов (примерно 36 тест-кейсов в день, или 4.5 в час). 


Подставим полученные значения в таблицу 2.6.а и получим таблицу 2.6.5. 


шиш! 2.6. ОЦЕНКА ТРУДОЗАТРАТ, ПЛАНИРОВАНИЕ И ОТЧЕТНОСТЬ 231 


Таблица 2.6.6 — Оценка трудозатрат 


Создание Выполнение 
Количество 12 22 
Повторения (проходы) 1 1.2 
Общее количество 12 26.4 
Время на один тест-кейс, ч 0.7 0.2 
Итоговое время, ч 8.4 5.2 
ИТОГО 13.6 часа 


Если бы оценка производительности нашего выдуманного тестировщика производилась 
на коротких отрезках времени, полученное значение нельзя было бы использовать напрямую, 
т.к. в нём не было бы учтено время на написание отчётов о дефектах, участие в различных со- 
браниях, переписку и прочие виды деятельности. Но мы потому и ориентировались на итоги 
измерений за месяц, что за 28 типичных рабочих дней все эти факторы многократно проявляли 
себя, и их влияние уже учтено в оценке производительности. 

Если бы мы всё же опирались на краткосрочные исследования, можно было бы ввести допол- 
нительный коэффициент или использовать допущение о том, что работе с тест-кейсами за один 
день удаётся посвятить не 8 часов, а меньше (например, 6). 

Итого у нас получилось 13.6 часа, или 1.7 рабочих дня. Помня идею о закладке небольшого 
«буфера», можем считать, что за два полных рабочих дня наш выдуманный тестировщик точно 
справится с поставленной задачей. 

В заключение этой главы ещё раз отметим, что для уточнения собственной производитель- 
ности и улучшения своих навыков оценки трудозатрат стоит формировать оценку, после чего 
выполнять работу и сравнивать фактический результат с оценкой. И повторять эту последова- 
тельность шагов раз за разом. 


деле 2.4, тест-кейсы и оцените свою производительность в процессе выполнения этой 


© Задание 2.6.с: разработайте на основе итогового чек-листа 53}, представленного в pas- 
задачи. 
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ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ 
РАЗЛИЧНЫХ ТЕХНИК 
ТЕСТИРОВАНИЯ 


2.7.1. ПОЗИТИВНЫЕ И НЕГАТИВНЫЕ 
ТЕСТ-КЕИСЫ mam 


Ранее мы уже рассматривали! 54} алгоритм продумывания идей тест-кейсов, в котором пред- 
лагается ответить себе на следующие вопросы относительно тестируемого объекта: 


e Что перед вами? 

e Кому и зачем оно нужно (и насколько это важно)? 

e Как оно обычно используется? 

e Как оно может сломаться, т.е. начать работать неверно? 


Сейчас мы применим этот алгоритм, сконцентрировавшись на двух последних вопросах, 
т.к. именно ответы на них позволяют нам придумать много позитивных!3} и негативных{83} 
тест-кейсов. Продолжим тестировать наш «Конвертер файлов!59)», выбрав для исследования 
первый параметр командной строки — SOURCE_DIR — имя каталога, в котором приложение 
ищет файлы, подлежащие конвертации. 


Что перед нами? Путь к каталогу. Казалось бы, просто, но стоит вспомнить, что наше при- 
ложение должно работать 60} как минимум под управлением Windows и Linux, что приводит к 
необходимости освежить в памяти принципы работы файловых систем в этих ОС. А ещё может 
понадобиться работа с сетью. 


Кому и зачем оно нужно (и насколько это важно)? Конечные пользователи не занимаются 
конфигурированием приложения, т.е. этот параметр нужен администратору (предположитель- 
но, это человек квалифицированный и не делает явных глупостей, но из его же квалификации 
вытекает возможность придумать такие варианты использования, до которых не додумается ря- 
довой пользователь). Важность параметра критическая, т.к. при каких-то проблемах с ним есть 
риск полной потери работоспособности приложения. 


Как оно обычно используется? Здесь нам понадобится понимание принципов работы фай- 
ловых систем. 


e Корректное имя существующего каталога: 
e Windows: 
a X:\dir 
“X:\dir with spaces” 
Айт 
„Лт 
\\host\dir 
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" Всё вышеперечисленное с “\” в конце пути. 
„ Х:\ 
e Linux: 
" /dir 
" “/dir with spaces” 
a host:/dir 
a smb://host/dir 
a ./dir 
a ../аіг 
" Всё вышеперечисленное с “/” в конце пути. 
" / 


И всё, т.е. в данном конкретном случае существует единственный вариант верного использо- 
вания первого параметра — указать корректное имя существующего каталога (пусть вариантов 
таких корректных имён и много). Фактически мы получили чек-лист для позитивного тести- 
рования. Все ли варианты допустимых имён мы учли? Может быть, и не все. Но эту проблему 
мы рассмотрим в следующей главе, посвящённой классам эквивалентности и граничным усло- 
виям(235}, 

В настоящий момент важно ещё раз подчеркнуть мысль о том, что сначала мы проверяем ра- 
боту приложения на позитивных тест-кейсах, т.е. в корректных условиях. Если эти проверки не 
пройдут, в некоторых совершенно допустимых и типичных ситуациях приложение будет нера- 
ботоспособным, т.е. ущерб качеству будет весьма ощутимым. 


Как оно может сломаться, т.е. начать работать неверно? Негативных тест-кейсов (за ред- 
чайшим исключением) оказывается намного больше, чем позитивных. Итак, какие проблемы с 
именем каталога-источника (и самим каталогом-источником) могут помешать нашему прило- 
жению? 


• Указанный путь не является корректным именем каталога: 


° Пустое значение (“”). 
° Слишком длинное имя: 

a Для Windows: более 256 символов. (Важно! Путь к каталогу длиной в 256 символов 
допустим, но надо учесть ограничение на полное имя файла, т.к. его превышение 
может быть достигнуто естественным образом, что приведёт к возникновению 
сбоя.) 

= Для Linux: более 4096 байт. 

° Недопустимые символы, например: ? < > \* | « \0. 
° Недопустимые комбинации допустимых символов, например: “....\ Чи”. 
e Каталог не существует: 
о На локальном диске. 
о В сети. 
e Каталог существует, но к нему нет прав доступа. 
• Доступ к каталогу утерян после запуска приложения: 
° Каталог удалён или переименован. 
° Изменены права доступа. 
° Потеря соединения с удалённым компьютером. 
» Использование зарезервированного имени: 


о Для Windows: сот1-сопа9, 1рї1-1рї9, con, nul, prn. 
о Для Linux: “ 


• Проблемы с кодировками, например: имя указано верно, но не в той кодировке. 
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Если погружаться в детали поведения отдельных операционных систем и файловых систем, 
данный список можно значительно расширить. И тем не менее открытыми будут оставаться два 
вопроса: 


• Bce ли эти варианты надо проверить? 
• Не упустили ли мы что-то важное? 


На первый вопрос ответ можно найти, опираясь на рассуждения, описанные в главе «Логи- 
ка создания эффективных проверок» 53}. Ответ на второй вопрос помогут найти рассуждения, 
описанные в двух следующих главах, т.к. классы эквивалентности, граничные условия и домен- 
ное тестирование значительно упрощают решение подобных задач. 


PF Задание 2.7.а: как вы думаете, почему в вышеприведённых чек-листах мы не учли тре- 
бование о том, что ЅООКСЕ РІК не может содержать внутри себя DESTINATION_DIR? 
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2.7.2. КЛАССЫ ЭКВИВАЛЕНТНОСТИ 
И ГРАНИЧНЫЕ УСЛОВИЯ iimmm 


В данной главе мы рассмотрим примеры упомянутых ранее техник тестирования на основе 
классов эквивалентности 6} и граничных условий 6}. Если уточнить определения, получается: 


Класс эквивалентности (equivalence с1аѕ349) — набор данных, обрабатываемых одина- 
ковым образом и приводящих к одинаковому результату. 


ЎЎ Граничное условие (border condition, boundary соп 101350) — значение, находящееся 
на границе классов эквивалентности. 


Иногда под классом эквивалентности понимают набор тест-кейсов, полное выполне- 
ние которого является избыточным. Это определение не противоречит предыдущему, 
т. к. показывает ту же ситуацию, но с другой точки зрения. 


В качестве пояснения идеи рассмотрим тривиальный пример. Допустим, нам нужно протести- 
ровать функцию, которая определяет, корректное или некорректное имя ввёл пользователь при 
регистрации. 

Требования к имени пользователя таковы: 


• Оттрёх до двадцати символов включительно. 
• Допускаются цифры, знак подчёркивания, буквы английского алфавита в верхнем и нижнем 
регистрах. 


Если попытаться решить задачу «в лоб», нам для позитивного тестирования придётся пере- 
брать все комбинации допустимых символов длиной [3, 20] (это 18-разрядное 63-ричное число, 
т.е. 2.4441614509104Е+32). А негативных тест-кейсов здесь и вовсе будет бесконечное количе- 
ство, ведь мы можем проверить строку длиной в 21 символ, 100, 10000, миллион, миллиард ит.д. 


Представим графически классы эквивалентности относительно требований к длине (см. ри- 
сунок 2.7.а). 


Недопустимо | | Допустимо Недопустимо 


Недостижимо 


Рисунок 2.7.а — Классы эквивалентности для значений длины имени пользователя 


Поскольку для длины строки невозможны дробные и отрицательные значения, мы видим три 
недостижимых области, которые можно исключить, и получаем окончательный вариант (см. ри- 
сунок 2.7.5). 


349 An equivalence class consists of a set of data that is treated the same Буа module ог that should produce the same result. 
[Lee Copeland, «A practitioner’s guide to software test design»] 


350 The boundaries — the «edges» of each equivalence class. [Lee Copeland, «A practitioner's guide to software test design»] 
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Мы получили три класса эквивалентности: 
• [0,2] — недопустимая длина; 

• [3,20] — допустимая длина; 

• [21, ә] — недопустимая длина. 


Недопустимо | | Допустимо Недопустимо 


Рисунок 2.7.6 — Итоговое разбиение на классы эквивалентности значений длины 
имени пользователя 


Обратите внимание, что области значений [0, 2] и [21, œ] относятся к разным классам экви- 
валентности, т.к. принадлежность длины строки к этим диапазонам проверяется отдельными 
условиями на уровне кода программы. 

Граничные условия уже отмечены на рисунке 2.7.6 — это 2, 3, 20 и 21. Значение 0 тоже стоит 
включить в этот набор на всякий случай, т.к. в программировании ноль, NULL, нулевой байт и 
т. п. исторически являются «опасными значениями». 

В итоге мы получаем следующий набор входных данных для тест-кейсов (сами символы для 
составления строк можно выбирать из набора допустимых символов случайным образом, но же- 
лательно учесть все типы символов, т.е. буквы в обоих регистрах, цифры, знак подчёркивания). 


Таблица 2.7.а — Значения входных данных для тест-кейсов 
(реакция на длину имени пользователя) 


Позитивные тест-кейсы Негативные тест-кейсы 
Пустая 
Значение ААА 123_ZZZZZZZZZZZZZZZZ | АА y 1234_ZZZZZZZZZZZZZZZZ 
строка 
Строка 
P Строка Строка 
мини- 
EHON Строка максималь- |недопусти- |недопусти- |Строка недопусти- 
мальной 5 . К „ Й 
Пояснение ной допустимой мой длины |мой длины, | мой длины по верх- 
допу- К > 
y , длины по нижней |учтенадля |нейгранице 
стимой 2, 
границе надёжности 
длины 


Осталось решить вопрос с недопустимыми символами. К сожалению, столь же наглядно, как 
с длиной, здесь не получится. Даже если подойти строго научно, т.е. выбрать кодировку и по её 
кодовой таблице определить диапазоны кодов символов (на рисунке 2.7.с приведён пример тако- 
го разделения для АЅСП-таблицы), у нас нет никакой гарантии, что символы с кодами из каждого 
диапазона трактуются единообразно. 


= Здесь мы видим ярчайший пример случая, в котором тестирование по методу белого 
О ящика сильно облегчило бы нам жизнь. Если бы мы видели, как в коде приложения ре- 


ализована проверка на допустимые и недопустимые символы, мы могли бы подобрать 
очень показательные значения входных данных. 
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Цифры Буквы A-Z а Буквы а-2 
48 57 65 90 9597 122 
и и п || иш п 


0 47 58 64 91 94 96 123 255 


Рисунок 2.7.с — Неудачный способ поиска классов эквивалентности для наборов 
допустимых и недопустимых символов (коды символов приведены по АЅСП-таблице) 


Раз оказалось, что по кодам символов подбирать классы эквивалентности в нашем случае не- 
рационально, посмотрим на ситуацию по-другому (и намного проще). Поделим символы на не- 
допустимые и допустимые, а последние, в свою очередь, — на группы (см. рисунок 2.7.4). 


Допустимо 


Недопустимо 


Буквы A-Z 
Буквы а-2 Все 
остальные 
Цифры символы 
Знак _ 


Рисунок 2.7.4 — Классы эквивалентных допустимых и недопустимых символов 


Интересующие нас комбинации допустимых символов (с представителями всех групп) мы уже 
учли при проверке реакции приложения на имена пользователя допустимых и недопустимых 
длин, потому остаётся учесть только вариант с допустимой длиной строки, но недопустимыми 
символами (которые можно выбирать случайным образом из соответствующего набора). В та- 
блицу 2.7.а добавим одну колонку и получим таблицу 2.7.Ъ. 


Таблица 2.7.6 — Значения всех входных данных для тест-кейсов 


Позитивные тест-кейсы Негативные тест-кейсы 
Значе- Пустая 
ААА 123_ZZZZZZZZZZZZZZZZ | АА y 1234_ZZZZZZZZZZZZZZZZ | #$% 
ние строка 
Строка Строка 
Строка Строка P P 
недопус- допус- 
мини- недопус- ` н 
„ | Строка максималь- Е тимой Строка недопусти- тимой 
Поясне- | мальной г А тимой 
ной допустимой длины, мой длины по верх- |длины, 
ние |допус- длины по ki 
Ё длины „ |учтена ней границе недопус- 
тимой нижней 
для на- тимые 
длины границе J 
дёжности символы 


ядерным реактором) мы бы проверили с помощью средств автоматизации реакцию 
приложения на каждый недопустимый символ. Но предположив, что перед нами некое 
тривиальное приложение, мы можем считать, что одной проверки на недопустимые 
символы будет достаточно. 


© Конечно, в случае критически важных приложений (например, системы управления 
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Теперь мы возвращаемся к «Конвертеру файлов» 3} и ищем ответ на вопрос 34} о том, не упус- 
тили ли мы какие-то важные проверки в главе «Позитивные и негативные тест-кейсы» {232}, 


Начнём с того, что выделим группы свойств SOURCE_DIR, от которых зависит работа прило- 
жения (такие группы называются «измерениями»): 


e Существование каталога (изначальное и во время работы приложения). 
• Длина имени. 

e Наборы символов в имени. 

• Комбинации символов в имени. 

• Расположение каталога (локальный или сетевой). 

• Права доступа к каталогу (изначальные и во время работы приложения). 
» Зарезервированные имена. 

• Поведение, зависящее от операционной системы. 

e Поведение, зависящее от работы сети. 


К°) Задание 2.7.Ъ: какие ещё группы свойств вы бы добавили в этот список и как бы вы 
выделили подгруппы у уже имеющихся в списке свойств? 


Очевидно, что отмеченные группы свойств оказывают взаимное влияние. Графически его 
можно отобразить в виде концепт-картыз5! (рисунок 2.7.е). 

Чтобы иметь возможность применить стандартную технику классов эквивалентности и гра- 
ничных условий, нам нужно по рисунку 2.7.е дойти от центрального элемента («SOURCE_DIR») 
до любого конечного, однозначно относящегося к позитивному или негативному тестированию. 

Один из таких путей на рисунке 2.7.е отмечен кружками. Словесно его можно выразить так: 
SOURCE_DIR > Windows > Локальный каталог > Имя > Свободное > Длина > В кодировке 
UTF16 > Допустимая или недопустимая. 

Максимальная длина пути для Windows в общем случае равна 256 символам: [диск] [:\] [путь] 
[null] =1+2 + 256 + 1 = 260. Минимальная длина равна 1 символу (точка обозначает «текущий 
каталог»). Казалось бы, всё очевидно и может быть представлено рисунком 2.7.Ё 


Недопустимо | | Допустимо 


0 257 
Рисунок 2.7. — Классы эквивалентности и граничные условия для длины пути 


Но если почитать внимательно спецификацию?52, выясняется, что «физически» путь может 
быть длиной до 32767 символов, а ограничение в 260 символов распространяется лишь на т.н. 
«полное имя». Потому возможна, например, ситуация, когда в каталог с полным именем длиной 
200 символов помещается файл с именем длиной 200 символов, и длина полного имени файла 
получается равной 400 символам (что очевидно больше 260). 

Так мы подошли к ситуации, в которой для проведения тестирования нужно либо знать вну- 
треннюю реализацию поведения приложения, либо вносить правки в требования, вводя искус- 


351 «Concept map», Wikipedia [http://en.wikipedia.org/wiki/Concept_map] 
352 «Naming Files, Paths, and Namespaces», MSDN [https://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath] 
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Права есть сс] Существует 
КК шы эши ашала а 
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Изначально Во время работы 
Особенности работы 
Права доступа бети 
Л 
С Особенности работы 
Существование 
ос 
Ө ЅООВСЕ рів 
Локальный Имя Сетевой 


Зарезервированное м 
Кодировки E Свободное N 


А | 
Символы Длина 


ү 
Недопустимые Допустимые Допустимая Недопустимая 
Недопустимые к | Комбинации символов — Допустимые 


Рисунок 2.7.е — Концепт-карта взаимовлияния групп свойств каталога 
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ственные ограничения (например, длина имени SOURCE_DIR не может быть более 100 симво- 
лов, а длина имени любого файла в SOURCE_DIR не может быть более 160 символов, что в сумме 
может дать максимальную длинув 260 символов). 

Ввод искусственных ограничений — плохая идея, потому с точки зрения качества мы вполне 
вправе считать представленное на рисунке 2.7 Ёразбиение корректным, а сбои в работе приложе- 
ния (если таковые будут), вызванные описанной выше ситуацией вида «200 символов + 200 сим- 


волов», — дефектом. 


Таблица 2.7.с — Значения всех входных данных для тест-кейсов по проверке выбранного 
на рисунке 2.7.е пути 


Позитивные тест-кейсы 


Негативные тест-кейсы 


Значение |. (точка) 


С: \256cumBonos 


Пустая строка С:\зз7символов 


Имя с мини- 
Пояснение | мальной допус- 
тимой длиной 


Имя с максимальной 
допустимой длиной 


Имя с недопусти- 
мой длиной, учтено 
для надёжности 


Имя с недопустимой 
длиной 


Итак, с одним путём на рисунке 2.7.е мы разобрались. Но их там значительно больше, и потому 
в следующей главе мы рассмотрим, как быть в ситуации, когда приходится учитывать влияние на 
работу приложения большого количества параметров. 
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2.7.3. ДОМЕННОЕ ТЕСТИРОВАНИЕ 
И КОМБИНАЦИИ ПАРАМЕТРОВ тавина 


Уточним данное ранее 7} определение: 


== Доменное тестирование (domain testing, domain апа|уз15353) — техника создания эф- 
фективных и результативных тест-кейсов в случае, когда несколько переменных могут 
или должны быть протестированы одновременно. 


В качестве инструментов доменного тестирования активно используются техники определе- 
ния классов эквивалентности и граничных условий, которые были рассмотрены в соответствую- 
щей!235) главе. Потому мы сразу перейдём к практическому примеру. 

На рисунке 2.7.е кружками отмечен путь, один из вариантов которого мы рассмотрели в пре- 
дыдущей главе, но вариантов может быть много: 


e Семейство ОС 
° Windows 
e Linux 
e Расположение каталога 


о Локальный 
° Сетевой 


» Доступность имени 


e Зарезервированное 
° Свободное 


e Длина 


° Допустимая 
° Недопустимая 


Чтобы не усложнять пример, остановимся на этом наборе. Графически комбинации вариантов 
можно представить в виде иерархии (см. рисунок 2.7.5). Исключив совсем нетипичную для на- 
шего приложения экзотику (всё же мы не разрабатываем сетевую утилиту), вычеркнем из списка 
случаи зарезервированных сетевых имён (отмечены на рисунке 2.7.5 серым). 

Легко заметить, что при всей своей наглядности графическое представление не всегда удобно 
в обработке (к тому же мы пока ограничились только общими идеями, не отметив конкретные 
классы эквивалентности и интересующие нас значения граничных условий). 

Альтернативным подходом является представление комбинаций в виде таблицы, которое 
можно получать последовательно за несколько шагов. 

Сначала учтём комбинации значений первых двух параметров — семейства ОС и расположе- 
ния каталога. Получается таблица 2.7.4. 


Таблица 2.7.4 — Комбинации значений первых двух параметров 


Локальный путь + + 


Сетевой путь + + 


353 Domain analysis is a technique that сап be used to identify efficient and effective test cases when multiple variables can 
or should be tested together. [Lee Copeland, «A practitioner’s guide to software test design»] 
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Рисунок 2.7.е — Графическое представление комбинаций параметров 
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ШИ 2.7. ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ РАЗЛИЧНЫХ ТЕХНИК ТЕСТИРОВАНИЯ 243 


На пересечении строк и столбцов можно отмечать необходимость выполнения проверки 
(в нашем случае таковая есть, потому там стоит «+») или её отсутствие, приоритет проверки, 
отдельные значения параметров, ссылки и т.д. 

Добавим третий параметр (признак зарезервированного имени) и получим таблицу 2.7.е. 


Таблица 2.7.е — Комбинации значений трёх параметров 


Windows Linux 
Локальный путь + + 
Зарезервированное имя - 
Сетевой путь - = 
Локальный путь + + 
Свободное имя - 
Сетевой путь + + 


Добавим четвёртый параметр (признак допустимости длины) и получим таблицу 2.7.Ё. Чтобы 
таблица равномерно увеличивалась по высоте и ширине, удобно добавлять каждый последую- 
щий параметр попеременно — то как столбец, то как строку. Третий параметр мы добавили как 
столбец, четвёртый добавим как строку. 


Таблица 2.7. — Комбинации значений четырёх параметров 


Недопустимая длина Допустимая длина 
Windows Linux Windows Linux 
Зарезервированное | Локальный путь - - + + 
имя Сетевой путь - - = Е 
Локальный путь + + + + 
Свободное имя - 
Сетевой путь + + + + 


Такое представление по сравнению с графическим оказывается более компактным и позво- 
ляет очень легко увидеть комбинации значений параметров, которые необходимо подвергнуть 
тестированию. Вместо знаков «+» в ячейки можно поставить ссылки на другие таблицы (хотя 
иногда все данные совмещают в одной таблице), в которых будут представлены классы эквива- 
лентности и граничные условия для каждого выбранного случая. 

Как несложно догадаться, при наличии большого количества параметров, каждый из кото- 
рых может принимать много значений, таблица наподобие 2.7.Ё будет состоять из сотен строк и 
столбцов. Даже её построение займёт много времени, а выполнение всех соответствующих про- 
верок и вовсе может оказаться невозможным в силу нехватки времени. В следующей главе мы 
рассмотрим ещё одну технику тестирования, призванную решить проблему чрезмерно большого 
количества комбинаций. 
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2.7.4. ПОПАРНОЕ ТЕСТИРОВАНИЕ 
И ПОИСК КОМБИНАЦИИ ЕШ 


Уточним данное ранее 7} определение: 


вместо проверки всех возможных комбинаций значений всех параметров проверяются 


Ө Попарное тестирование (pairwise {езНп9354) — техника тестирования, в которой 
только комбинации значений каждой пары параметров. 


Выбрать и проверить пары значений — звучит вроде бы просто. Но как выбирать такие пары? 
Существует несколько тесно взаимосвязанных математических методов создания комбинаций 
всех пар: 


• на основе ортогональных массивов355 359; 
• на основе латинских квадратов356; 

e ІРО (in parameter order) метод357; 

• на основе генетических алгоритмов358; 

• на основе рекурсивных алгоритмов?5°. 


Глубоко в основе этих методов лежит серьёзная математическая теория35. В упрощён- 
ном виде на примерах суть и преимущества этого подхода показаны в книге Ли Ко- 
упленда360 и статье Майкла Болтона355, а справедливая критика — в статье Джеймса 
Баха361. 


Итак, суть проблемы: если мы попытаемся проверить все сочетания всех значений всех па- 
раметров для более-менее сложного случая тестирования, мы получим количество тест-кейсов, 
превышающее все разумные пределы. 

Если представить изображённую на рисунке 2.7.е схему в виде набора параметров и количе- 
ства их значений, получается ситуация, представленная таблицей 2.7.5. Минимальное количе- 
ство значений получено по принципу «расположение: локально или в сети», «существование: 
да или нет», «семейство ОС: Windows или Linux» и т.д. Вероятное количество значений оценено 
исходя из необходимости учитывать несколько классов эквивалентности. Количество значений 
с учётом полного перебора получено исходя из технических спецификаций операционных си- 
стем, файловых систем и т.д. Значение нижней строки получено перемножением значений в CO- 
ответствующей колонке. 


354 The answer is not to attempt to test all the combinations for all the values for all the variables but to test all pairs of 
variables. [Lee Copeland, «A practitioner’s guide to software test design»] 

355 «Pairwise Testing», Michael Bolton [http://www.developsense.com/pairwiseTesting.html] 

356 «An Improved Test Generation Algorithm for Pair-Wise Testing», Soumen Maity and oth. [http://www.iiserpune. 
ac.in/~soumen/115-FA-2003.pdf] 

357 «A Test Generation Strategy for Pairwise Testing», Kuo-Chung Tai, Yu Lei [http://www.cs.umd.edu/class/spring2003/ 
cmsc838p/VandV /pairwise.pdf] 

358 «Evolutionary Algorithm for Prioritized Pairwise Test Data Generation», Javier Ferrer and oth. [http://neo.lcc.uma.es/ 
staff/javi/files/gecco12.pdf] 

359 «On the Construction of Orthogonal Arrays and Covering Arrays Using Permutation Groups», George Sherwood 
[http://testcover.com/pub/background/cover.htm] 

360 «A Practitioner's Guide to Software Test Design», Lee Copeland. 


361 «Pairwise Testing: A Best Practice That Isnt», James Bach [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1. 
105.3811&тер=гер1&уре=раї]. 
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Таблица 2.7.9 — Список параметров, влияющих на работу приложения 


Параметр Минимальное komi Вероятное воли Количество значений 
чество значений | чество значений | сучётом полного перебора 
Расположение 2 25 32 
Существование 2 2 2 
Наличие прав доступа 2 3 155 
Семейство ОС 2 4 28 
о | 4 23 
Кодировки 2 3 16 
Длина 2 4 4096 
Комбинации символов 2 4 82 
ИТОГО тест-кейсов 256 2017600 342331°384°872?960 


Конечно, мы не будем перебирать все возможные значения (для того нам и нужны классы 
эквивалентности), но даже 256 тест-кейсов для проверки всего лишь одного параметра команд- 
ной строки — это много. И куда вероятнее, что придётся выполнять около 200 тысяч тест-кейсов. 
Если делать это вручную и выполнять по одному тесту в пять секунд круглосуточно, понадобит- 
ся около 11 суток. 

Но мы можем применить технику попарного тестирования для генерации оптимального на- 
бора тест-кейсов, учитывающего сочетание пар каждого значения каждого параметра. Опишем 
сами значения. Обратите внимание, что уже на этой стадии мы провели оптимизацию, собрав в 
один набор информацию о расположении, длине, значении, комбинации символов и признаке 
зарезервированного имени. Это сделано потому, что сочетания вида «длина 0, зарезервирован- 
ное имя COMl» не имеют смысла. Также мы усилили часть проверок, добавив русскоязычные 
названия каталогов. 


Таблица 2.7.h — Список параметров и их значений 


Параметр Значения 
1. ХА 

2. X:\dir 

3. “ХАпробелы и русский” 
4. Adir 
5 

6 

7 


„Аа 

\\host\dir 

[256 символов только для Windows] 
+ Пункты 2-6 с “\” в конце пути. 


8. / 

9. /dir 

10. “/пробелы и русский” 

11. host:/dir 

12. smb://host/dir 

13. ./dir 

14. ../аіг 

15. [4096 символов только для Linux] 
+ Пункты 9-14 с “/” в конце пути. 


Расположение / длина / значе- 
ние / комбинация символов / 
зарезервированное или сво- 
бодное 
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Таблица 2.7.ћ [окончание] 


Параметр 


Значения 


Недопустимое имя. 


16. 
17. 
18. 
19. 
20. 
21. 


[0 символов] 
[4097 символов только для Linux] 
[257 символов только для Windows] 


22. 


23. 
24. 
25. 
26. 
27. 


coml-com9 
lpt1-lpt9 
con 

nul 

prn 


Существование 


Да 
Нет 


1. К каталогу и его содержимому 
Наличие прав доступа 2. Только к каталогу 
3. Ни ккаталоту, ни к его содержимому 
1. Windows 32 bit 
> 2. Windows 64 bit 
о 3. Linux 32 bit 
4. Linux 64bit 
1. UTF8 
Кодировки 2. UTF16 
3. ОЕМ 


Количество потенциальных тест-кейсов уменьшилось до 2736 (38*2*3*4*3), что уже много 


меньше 200 тысяч, но всё равно нерационально. 


Теперь воспользуемся любым из представленных в огромном количестве инструментальных 


средств36? (например, РІСТ) и сгенерируем набор комбинаций на основе попарного сочетания 


всех значений всех параметров. Пример первых десяти строк результата представлен в табли- 
це2.7.1. Всего получилось 152 комбинации, т.е. в 1326 раз меньше (2017600 / 152) исходной оценки 


илив 18 раз меньше (2736 / 152) оптимизированного варианта. 
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Таблица 2.714 — Наборы значений, полученные методом попарных комбинаций 
Расположение / 
длина / значение / Cect: Коди- 
№ | комбинация символов / уш Наличие прав доступа Семейство ОС А 
вование ровки 
зарезервированное 
или свободное 
1 [ХА Да К каталогу и его содержимому | Windows 64 bit | UTF8 
2 |smb://host/dir/ Нет |Ни к каталогу, ни к его содер- |у, ии gd bit UTF 
жимому 
3 |/ Нет |Только к каталогу Windows 32 bit | ОЕМ 
4 |[0 символов] Да Только к каталогу Linux 32 bit UTF8 
5 |smb://host/dir Нет |K каталогу и его содержимому | Linux 32 bit UTF16 
6 |../dir о [OEM 
жимому 
7 ый о. те Да Только к каталогу Windows 64 bit | ОЕМ 
для Windows] 
8 [4096 символов только Her Ни к каталогу, ни K его содер- Windows 32 bit |ОТЕ8 
для Linux] жимому 
9 [256 символов только Нет Ни к каталогу, ни к его содер- Linux 32 bit OEM 
для Windows] жимому 
10 | /dir/ Да Только к каталогу Windows 32 Би | UTF16 


Если исследовать набор полученных комбинаций, можно исключить из них те, которые не 
имеют смысла (например, существование каталога с именем нулевой длины или проверку под 
Windows характерных только для Linux случаев — см. строки 4 и 8). Завершив такую операцию, 
мы получаем 124 комбинации. По соображениям экономии места эта таблица не будет приведе- 
на, но в приложении «Пример данных для попарного тестирования» 301} представлен конечный 
итог оптимизации (из таблицы убраны ещё некоторые комбинации, например, проверка под 
Linux имён, являющихся зарезервированными для Windows). Получилось 85 тест-кейсов, что 
даже немного меньше минимальной оценки в 256 тест-кейсов, и при этом мы учли куда больше 
опасных для приложения сочетаний значений параметров. 


О 


Задание 2.7.с: в представленной в приложении «Пример данных для попарного тести- 
рования»!30!) в колонке «Наличие прав доступа» иногда отсутствуют значения. Как вы 
думаете, почему? Также в этой таблице всё ещё есть «лишние» тесты, выполнение кото- 


рых не имеет смысла или представляет собой крайне маловероятный вариант стечения 
событий. Найдите их. 


Итак, на протяжении последних четырёх глав мы рассмотрели несколько техник тестирова- 
ния, позволяющих определить наборы данных и идей для написания эффективных тест-кейсов. 
Следующая глава будет посвящена ситуации, когда времени на столь вдумчивое тестирова- 
ние нет. 
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2.7.5. ИССЛЕДОВАТЕЛЬСКОЕ 
ТЕСТИРОВАНИЕ Em 


Исследовательское!7} и свободное! 7} тестирование уже было упомянуто ранее на уровне 
определения. Для начала ещё раз подчеркнём, что это разные виды тестирования, пусть в каж- 
дом из них степень формализации процесса значительно меньше, чем в тестировании на основе 
тест-кейсові87). Сейчас мы будем рассматривать применение именно исследовательского тести- 
рования. 

Сэм Kanep определяет?6? исследовательское тестирование как стиль, основанный на свободе 
и ответственности тестировщика в непрерывной оптимизации своей работы за счёт выполняе- 
мых параллельно на протяжении всего проекта и взаимодополняющих изучения, планирования, 
выполнения проверок и оценки их результатов. Если сказать короче, исследовательское тестиро- 
вание — это одновременное изучение, планирование и тестирование. 

Кроме очевидной проблемы с тестированием на основе тест-кейсов, состоящей в высоких за- 
тратах времени, существует ещё одна — существующие техники оптимизации направлены на то, 
чтобы максимально исследовать приложение во всех учтённых ситуациях, которые мы можем 
контролировать — но невозможно учесть и проконтролировать всё. Эта идея визуально пред- 
ставлена на рисунке 2.7.Һ. 


Неучтённые состояния ОС и Неучтённые состояния ОС и 
среды выполнения среды выполнения 
Неучтённые состояния Неучтённые состояния 
компонентов приложения компонентов приложения 
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Подготовленные Контролируемое 


данные и команды Приложение 


Неучтённые состояния Неучтённые воздействия на 
конфигураций и ресурсов разнообразные ресурсы 
Неучтённые воздействия Неучтённые воздействия на 

других приложений другие приложения 


Рисунок 2.7. — Факторы, которые могут быть пропущены тестированием 
на основе тест-кейсов363 


поведение 


Исследовательское же тестирование часто позволяет обнаружить дефекты, вызванные этими 
неучтёнными факторами. К тому же оно прекрасно показывает себя в следующих ситуациях: 


e Отсутствие или низкое качество необходимой документации. 

e Необходимость быстрой оценки качества при нехватке времени. 

» Подозрение на неэффективность имеющихся тест-кейсов. 

» Необходимость проверить компоненты, разработанные «третьими сторонами». 

• Верификация устранения дефекта (для проверки, что он не проявляется при незначитель- 
ном отступлении от шагов воспроизведения). 


363 «А Tutorial in Exploratory Testing», Сет Kaner [http://www.kaner.com/pdfs/QAIExploring.pdf] 
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В своей работе363 Сэм Канер подробно показывает способы проведения исследовательского 
тестирования с использованием базовых методов, моделей, примеров, частичных изменений 
сценариев, вмешательства в работу приложения, проверки обработки ошибок, командного тес- 
тирования, сравнения продукта с требованиями, дополнительного исследования проблемных 
областей и т.д. 

Вернёмся к нашему «Конвертеру файлов» 5}. Представим следующую ситуацию: разработчи- 
ки очень уж быстро выпустили первый билд, тест-кейсов (и всех тех наработок, что были рас- 
смотрены ранее в этой книге) у нас пока нет, а проверить билд нужно. Допустим, в уведомлении 
о выходе билда сказано: «Реализованы и готовы к тестированию требования: СХ-1, СХ-2, СХ-3, 
ПТ-1.1, 071.2 ПТ-2.1, ПТ-3.1, ПТ 2, БП-1.1, БП-1.2‚ ДС-1.1, ДС-2.1, ДС-2.2,‚ ДС-2.3, ДС-2.4, 
ДС-3.1, ДС-3.2 (текст сообщений приведён к информативному виду), ДС-4.1, ДС-4.2, ДС-4.3». 


Ранее мы отметили, что исследовательское тестирование — это тесно взаимосвязанные изуче- 
ние, планирование и тестирование. Применим эту идею. 


ИЗУЧЕНИЕ 


Представим полученную от разработчиков информацию в виде таблицы 2.7.) и проанализиру- 
ем соответствующие требования, чтобы понять, что нам нужно будет сделать. 


Таблица 2.7.] — Подготовка к исследовательскому тестированию 


Требование Что и как будем делать 

СХ-1 Не требует отдельной проверки, т. к. вся работа с приложением будет выпол- 
няться в консоли. 

СХ-2 Не требует отдельной проверки, видно по коду. 

СХ-3 Провести тестирование под Windows и Linux. 

ПТ-1.1 

ДС-2.1 Стандартная проверка реакции консольного приложения на различные вари- 

ДС-22 анты указания параметров. Учесть, что обязательными являются первые два 
параметра из трёх (третий принимает значение по умолчанию, если не задан). 

ДС-2.3 См. «Идеи», пункт 1. 

ДС-2.4 

ПТ-1.2 См. «Идеи», пункт 2. 

ПТ-2.1 Не требует отдельной проверки, покрывается другими тестами. 

ПТ-3.1 

ПТ-3.2 

ДС-41 На текущий момент можно только проверить факт ведения лога и формат запи- 

ДС-42 сей, т. к. основная функциональность ещё не реализована. См. «Идеи», пункт 4. 

ДС-4.3 

о См. «Идеи», пункт 3. 

БП-1.2 

ДС-1.1 Тестирование проводить на РНР 5.5. 

ДС-3.1 Проверять выводимые сообщения в процессе выполнения пунктов 1-2 

ДС-3.2 (см. «Идеи»). 

ПЛАНИРОВАНИЕ 


Частично планированием можно считать колонку «Что и как будем делать» таблицы 2.7.], но 
для большей ясности представим эту информацию в виде обобщённого списка, который для 
простоты назовём «идеи» (да, это — вполне классический чек-лист). 
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Идеи: 
1. Проверить сообщения в ситуациях запуска: 
а. Без параметров. 
b. С верно указанными одним, двумя, тремя параметрами. 
с. С неверно указанными первым, вторым, третьим, одним, двумя, тремя параметрами. 
2. Остановить приложение по Ctrl+C. 
3. Проверить сообщения в ситуациях запуска: 
а. Каталог-приёмник и каталог-источник в разных ветках ФС. 
b. Каталог-приёмник внутри каталога-источника. 
с. Каталог-приёмник, совпадающий с каталогом-источником. 


4. Проверить содержимое лога. 
5. Посмотреть в код классов, отвечающих за анализ параметров командной строки и ведение 
лога. 


==. Задание 2.7.4: сравните представленный набор идей с ранее рассмотренными подхода- 
Ө ми{153), {232}, {235}, {241}, {244} — какой вариант вам кажется более простым в разработке, 


а какой в выполнении и почему? 


Итак, список идей есть. Фактически, это почти готовый сценарий, если пункт 2 (про остановку 
приложения) повторять в конце проверок из пунктов 1 и 3). 


ТЕСТИРОВАНИЕ 


Можно приступать к тестированию, но стоит отметить, что для его проведения нужно привле- 
кать специалиста, имеющего богатый опыт работы с консольными приложениями, иначе тести- 
рование будет проведено крайне формально и окажется неэффективным. 

Что делать с обнаруженными дефектами? Для начала — фиксировать в таком же формате, 
т.е. как список идей: переключение между прохождением некоего сценария и написанием отчёта 
о дефекте сильно отвлекает. Если вы опасаетесь что-то забыть, включите запись происходящего 
на экране (отличный трюк — записывать весь экран так, чтобы были видны часы, а в списках 
идей отмечать время, когда вы обнаружили дефект, чтобы потом в записи его было проще найти). 

Список «идей дефектов» можно для удобства оформлять в виде таблицы (см. таблицу 2.7.К). 

Выводы по итогам тестирования (которое, к слову, заняло около получаса): 


e Нужно подробно обсудить с заказчиком форматы и содержание сообщений об использова- 
нии приложения и об ошибках, а также формат записей лог-файла. Разработчики предло- 
жили идеи, выглядящие куда более адекватно, чем изначально описано в требованиях, HO 
всё равно нужно согласование. 

• Под Windows серьёзных дефектов не обнаружено, приложение вполне работоспособно. 

• Под Linux есть критическая проблема с исчезновением «/» в начале пути, что не позволяет 
указывать абсолютные пути к каталогам. 

• Если обобщить вышенаписанное, то можно констатировать, что дымовой тест успешно 
пройден под Windows и провален под Linux. 


Цикл «изучение, планирование, тестирование» можно многократно повторить, дополняя и 
рассматривая список обнаруженных проблем (таблица 2.7.К) как новую информацию для изуче- 
ния, ведь каждая такая проблема даёт пищу для размышлений и придумывания дополнительных 
тест-кейсов. 
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Таблица 2.7.К — Список «идей дефектов» 


Что делали 


Что получили 


Что ожидали / Что не так 


а) Во всех случаях сообщения приложения вполне корректны с точки зрения происходя- 
щего и информативны, но противоречат требованиям (обсудить с заказчиком изменения в 


требованиях). 


6) Лог ведётся, формат даты-времени верный, но нужно уточнить, что в требованиях имеет- 
ся в виду под «имя_операции параметры_операции результат_операции», т. к. для разных 
операций единый формат не очень удобен — нужно ли приводить всё к одному формату 


или нет? 


php converter.php 


php converter.php zzz:/ с:/ 


Error: Too few command line parameters. 
USAGE: php converter.php SOURCE_ 
DIR DESTINATION_DIR [LOG_FILE_ 
NAME] 

Please note that DESTINATION_DIR 
may NOT be inside SOURCE_DIR. 


Error: SOURCE_DIR пате [zzz:] is not a 
valid directory. 


Сообщение совершенно не соот- 
ветствует требованиям. 


Странно, что от «222:/» осталось 
ТОЛЬКО «7771». 


php  сопуемегрЬр «с:/поп/ 


existing/directory/» с:/ 


Error: ЅООКСЕ РІК пате [с\поп\ 
existing\directory] is not a valid directory. 


Слеши заменены на бэк-слеши, 
конечный бэк-слеш удалён: так 
и надо? Глянуть в коде, пока не 
ясно, дефект это или так и заду- 
мано. 


php сопуецег.рЬр с:/ 4:/ 2015.06.12 13:37:56 Started with Буквы дисков приведены к верх- 
parameters: SOURCE_DIR=[C:\], нему регистру, слеши замене- 
DESTINATION_DIR=[D:\], LOG_ 6 П 
ЕПЕ МАМЕ=[\сопуегќег 06] Ны ч эк-елепит көчем MMA 
лог-файла относительное? 
php converter.php с:/ с:/ Error: DESTINATION_DIR [С:\] апа | Опечатка в сообщении. Явно 


SOURCE_DIR [С:\] mat МОТ be the 
same dir. 


должно быть ти$ї или тау. 


php сопуемег.рЬр «с:/каталог 
с русским именем/» с:/ 


Error: SOURCE_DIR name [с:\ 
ърЄрыюу ë Ёєёёъшь шьхэхь] is not a 
valid directory. 


Дефект: проблема с кодиров- 
ками. 


php converter.php / c:/Windows/ 
Temp 


Error: SOURCE_DIR пате [] is not a 
valid directory. 


Проверить под Linux: маловеро- 
ятно, конечно, что кто-то прямо 
в / будет что-то рабочее хра- 
нить, но имя «/» урезано до пу- 
стой строки, что допустимо для 
Windows, но не для Linux. 


Примечание: «е:» -- РУР-при- 
вод. 
php сопуекег.рЬр с:/ е:/ 


file_put_contents(e:f41c7142310c591 
0e2cfb57993b4d004620aa3b8): failed 
to open stream: Permission denied in 
\classes\CLPAnalyser.class.php at line 70 
Error: DESTINATION_DIR [e] is not 
writeable. 


Дефект: сообщение от РНР не 
перехвачено. 


php сопуемегрЬр /var/www / 
var/www/1 


Error: SOURCE_DIR name [var/www] is 
not a valid directory. 


Дефект: в Linux обрезается Ha- 
чальный «/» в имени каталога, 
т.е. можно смело считать, что 
под Linux приложение нерабо- 
тоспособно (можно задавать 
только относительные пути, на- 
чинающиеся с «.» или «..»). 
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\\ Задание 2.7.е: опишите дефекты, представленные в таблице 2.7.К в виде полноценных 
отчётов о дефектах. 


В данной главе в таблице 2.7.К некоторые пункты представляют собой очевидные дефекты. 
Но что их вызывает? Почему они возникают, как могут проявляться и на что влиять? Как описать 
их максимально подробно и правильно в отчётах о дефектах? Ответам на эти вопросы посвяще- 
на следующая глава, в которой мы поговорим о поиске и исследовании причин возникновения 
дефектов. 
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2.7.6. ПОИСК ПРИЧИН 
ВОЗНИКНОВЕНИЯ ДЕФЕКТОВ Immm 


Ранее мы отмечали 68}, что используем слово «дефект» для обозначения проблемы потому, 
что описание конечного симптома несёт мало пользы, а выяснение исходной причины может 
быть достаточно сложным. И всё же наибольший эффект приносит как раз определение и устра- 
нение первопричины, что позволяет снизить риск появления новых дефектов, обусловленных 
той же самой (ненайденной и неустранённой) недоработкой. 


ции первопричин возникновения событий, негативно влияющих на безопасность, здо- 


© Анализ первопричин (root cause апа|у$15364) — процесс исследования и классифика- 
ровье, окружающую среду, качество, надёжность и производственный процесс. 


Как видно из определения, анализ первопричин не ограничивается разработкой программ, 
но нас он будет интересовать всё же в ИТ-контексте. Часто ситуация, в которой тестировщик 
пишет отчёт о дефекте, может быть отражена рисунком 2.7.1. 


Наблюдаемое проявление 
Причина N-1 


Условия, способствовавшие 
возникновению первопричины 


Рисунок 2.7.1 — Проявление и причины дефекта 


В самом худшем случае проблема вообще будет пропущена (не замечена), и отчёт о дефекте не 
будет написан. Чуть лучше выглядит ситуация, когда отчёт описывает исключительно внешние 
проявления проблемы. Приемлемым может считаться описание лежащих на поверхности при- 
чин. Но в идеале нужно стремиться добраться до двух самых нижних уровней — первопричины 


364 Root cause analysis (RCA) is а process designed for use in investigating and categorizing the root causes of events 
with safety, health, environmental, quality, reliability and production impacts. [James Rooney and Lee Vanden Heuvel, «Root 
Cause Analysis for Beginners», https://www.env.nm.gov/aqb/Proposed_Regs/Part_7_Fxcess_Emissions/NMED_Exhibit_18- 
Root_Cause_Analysis_for_Beginners.pdf] 


Раздел 2: ОСНОВНЫЕ ЗНАНИЯ И УМЕНИЯ ШШШ 


254 


и условий, способствовавших её возникновению (хоть последнее часто и лежит в области управ- 
ления проектом, а не тестирования как такового). 


Вкратце вся эта идея выражается тремя простыми пунктами. Нам нужно понять: 


• Что произошло. 
• Почему это произошло (найти первопричину). 
• Как снизить вероятность повторения такой ситуации. 


Сразу же рассмотрим практический пример. В таблице 2.7.К в строке с номером 90251) есть 
упоминание крайне опасного поведения приложения под Linux — из путей, переданных прило- 
жению из командной строки, удаляется начальный символ «/», что для Linux приводит к некор- 
ректности любого абсолютного пути. 


Пройдём по цепочке, представленной рисунком 2.7.1, и отразим этот путь таблицей 2.7.1: 


Таблица 2.7.1 — Пример поиска первопричины 


Уровень анализа 


Наблюдаемая ситуация 


Рассуждения и выводы 


Наблюдаемое 
проявление 
проблемы 


Тестировщик выполнил команду «php 
сопуецег.рЬр /var/www /var/www/1» 
и получил такой ответ приложения: 
«Error: SOURCE_DIR name [var/www] 
is not a valid directory.» в ситуации, 
когда указанный каталог существует и 
доступен для чтения. 


Сразу же бросается в глаза, что в 
сообщении об ошибке имя каталога 
отличается от заданного — отсут- 
ствует начальный «/». Несколько 
контрольных проверок подтвержда- 
ют догадку — во всех параметрах 
командной строки начальный «/» 
удаляется из полного пути. 


© 


На этом этапе очень часто начинающие тестировщики описывают дефект как «невер- 
но распознаётся имя каталога», «приложение не обнаруживает доступные каталоги» 
и тому подобными словами. Это плохо как минимум по двум причинам: а) описание 


дефекта некорректно; 6) программисту придётся самому проводить всё исследование. 


Таблица 2.7.1 [продолжение] 


Уровень анализа 


Наблюдаемая ситуация 


Рассуждения И выводы 


Причина М 


Факт: во всех параметрах командной 
строки начальный «/» удаляется из 
полного пути. Проверка с относитель- 
ными путями («php сопуецег.рЬр . .») и 
проверка под Windows («php converter. 
php c:\ 4:\») показывает, что в таких 
ситуациях приложение работает. 


Дело явно в обработке введённых 
имён: в некоторых случаях имя 06- 
рабатывается корректно, в некото- 
рых — нет. 

Гипотеза: убираются начальные и 
концевые «/» (может быть, ещё 
и «\»). 


Причина N-1 


Проверки «php сопуемег.рЬр \\\\\с:\\\\\ 
\\\\\4А\\\\» и «php  сопуемегрЬр 
/1111:/1111 ПИЯ показывают, что 
приложение под Windows запуска- 
ется, корректно распознав правиль- 
ные пути: «Started with parameters: 
SOURCE_DIR=[C:\], DESTINATION_ 
DIR=[D:\]» 


Гипотеза подтвердилась: из имён 
каталогов приложение убирает все 
«/» и «\», в любом количестве при- 
сутствующие в начале или конце 
имени. 


В принципе, на этой стадии уже можно писать отчёт о дефекте с кратким описанием в стиле 
«Удаление краевых “/” и “\ из параметров запуска повреждает абсолютные пути в Linux ФС». 
Но что нам мешает пойти ещё дальше? 
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Уровень 
анализа 


Таблица 2.7.1 [окончание] 


Наблюдаемая ситуация 


Рассуждения и выводы 


Причина 
N-2 


Гипотеза: где-то в коде есть первичный фильтр NO- 
лученных значений путей, который обрабатывает их 
до начала проверки каталога на существование. Этот 
фильтр работает некорректно. Откроем код класса, 
отвечающего за анализ параметров командной стро- 
ки. Очень быстро мы обнаруживаем метод, который 
виновен в происходящем: 

private function дееСапор1са1Маме ($name) 


{ 


$name = str_replace('\\'; '/', $name); 
Ѕагг = ехр1оде('/', $name); 
$name = trim(implode (DIRECTORY ЅЕРАРАТОР, 


$arr), DIRECTORY SEPARATOR) Ы 
return $name; 


} 


Мы нашли конкретное место 
в коде приложения, которое 
является первопричиной об- 
наруженного дефекта. Ин- 
формацию об имени файла, 
номере строки и выдержку 
самого кода с пояснениями, 
что в нём неверно, можно 
приложить в комментарии к 
отчёту о дефекте. Теперь про- 
граммисту намного проще 
устранить проблему. 


— Задание 2.7.Ё представьте, что программист исправил проблему сменой удаления Kpa- 


евых «/» и «\» на концевые (т. е. теперь они удаляются только в конце имени, но не в 


начале). Хорошее ли это решение? 


Обобщённый алгоритм поиска первопричин можно сформулировать следующим образом 


(см. рисунок 2.7.]}: 


e Определить проявление проблемы 


° Что именно происходит? 


° Почему это плохо? 


Собрать необходимую информацию 


° Происходит ли то же самое в других ситуациях? 


° Всегда ли оно происходит одинаковым образом? 


о Отчего зависит возникновение или исчезновение проблемы? 


e Выдвинуть гипотезу о причине проблемы 


° Что может являться причиной? 


° Какие действия или условия могут приводить к проявлению проблемы? 


° Какие другие проблемы могут быть причинами наблюдаемой проблемы? 


• Проверить гипотезу 


ш Провести дополнительное исследование. 


° Если гипотеза не подтвердилась, проработать другие гипотезы. 


• Убедиться, что обнаружена именно первопричина, а не очередная причина в длинной цепи 


событий 


° Если обнаружена первопричина — сформировать рекомендации по её устранению. 


° Если обнаружена промежуточная причина, повторить алгоритм для неё. 
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Здесь мы рассмотрели очень узкое применение поиска первопричин. Но представлен- 
© ный алгоритм универсален: он работает и в разных предметных областях, и в управле- 


нии проектами, и в работе программистов (как часть процесса отладки). 


Определить 
проявление 
проблемы 


l 


Собрать 
необходимую 
информацию 


l 


Выдвинуть гипотезу 
о причине проблемы 


| 


Проверить 
выдвинутую гипотезу 


Гипотеза 
подтвердилась? 


Это первопричина? 


Сформировать 
рекомендации по 
устранению 


Рисунок 2.7.] — Алгоритм поиска первопричины дефекта 


Наэтом мы завершаем основную часть данной КНИГИ, посвящённую «тестированию в принци- 
пе». Далее будет рассмотрена автоматизация тестирования как совокупность техник, повышаю- 
щих эффективность работы тестировщика по многим показателям. 
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АВТОМАТИЗАЦИН 
ТЕСТИРОВАНИЯ 


РАЗДЕЛ 


ВЫГОДЫ И РИСКИ 
АВТОМАТИЗАЦИИ 


3.1.1. ПРЕИМУЩЕСТВА И НЕДОСТАТКИ 
АВТОМАТИЗАЦИИ тивна 


В разделе, посвящённом подробной классификации тестирования}, мы кратко рассматрива- 
ли, что собой представляет автоматизированное тестирование!” 3: это набор техник, подходов и 
инструментальных средств, позволяющий исключить человека из выполнения некоторых задач 
в процессе тестирования. В таблице 2.3176 был приведён краткий список преимуществ и недо- 
статков автоматизации, который сейчас мы рассмотрим подробно. 


» Скорость выполнения тест-кейсов может в разы и на порядки превосходить возможности 
человека. Если представить, что человеку придётся вручную сверять несколько файлов раз- 
мером в несколько десятков мегабайт каждый, оценка времени ручного выполнения стано- 
вится пугающей: месяцы или даже годы. При этом 36 проверок, реализуемых в рамках ды- 
мового тестирования командными скриптами! 86}, выполняются менее чем за пять секунд и 
требуют от тестировщика только одного действия — запустить скрипт. 

e Отсутствует влияние человеческого фактора в процессе выполнения тест-кейсов (устало- 
сти, невнимательности и т.д.) Продолжим пример из предыдущего пункта: какова вероят- 
ность, что человек ошибётся, сравнивая (посимвольно!) даже два обычных текста размером 
в 100 страниц каждый? А если таких текстов 10? 20? И проверки нужно повторять раз за 
разом? Можно смело утверждать, что человек ошибётся гарантированно. Автоматика не 
ошибётся. 

e Средства автоматизации способны выполнить тест-кейсы, в принципе непосильные для 
человека в силу своей сложности, скорости или иных факторов. И снова наш пример со 
сравнением больших текстов является актуальным: мы не можем позволить себе потратить 
годы, раз за разом выполняя крайне сложную рутинную операцию, в которой мы к тому же 
будем гарантированно допускать ошибки. Другим прекрасным примером непосильных для 
человека тест-кейсов является исследование производительности3}, в рамках которого не- 
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обходимо с высокой скоростью выполнять определённые действия, а также фиксировать 
значения широкого набора параметров. Сможет ли человек, например, сто раз в секунду 
измерять и записывать объём оперативной памяти, занимаемой приложением? Нет. Авто- 
матика сможет. 

Средства автоматизации способны собирать, сохранять, анализировать, агрегировать и 
представлять в удобной для восприятия человеком форме колоссальные объёмы данных. 
В нашем примере с дымовым тестированием «Конвертера файлов» объём данных, получен- 
ный в результате тестирования, невелик — его вполне можно обработать вручную. Но если 
обратиться к реальным проектным ситуациям, журналы работы систем автоматизирован- 
ного тестирования могут занимать десятки гигабайт по каждой итерации. Логично, что че- 
ловек не в состоянии вручную проанализировать такие объёмы данных, но правильно на- 
строенная среда автоматизации сделает это сама, предоставив на выход аккуратные отчёты 
в 2-3 страницы, удобные графики и таблицы, а также возможность погружаться в детали, 
переходя от агрегированных данных к подробностям, если в этом возникнет необходимость. 
Средства автоматизации способны выполнять низкоуровневые действия с приложением, 
операционной системой, каналами передачи данных и т.д. В одном из предыдущих пунктов 
мы упоминали такую задачу, как «сто раз в секунду измерить и записать объём оперативной 
памяти, занимаемой приложением». Подобная задача сбора информации об используемых 
приложением ресурсах является классическим примером. Однако средства автоматизации 
могут не только собирать подобную информацию, но и воздействовать на среду исполне- 
ния приложения или само приложение, эмулируя типичные события (например, нехватку 
оперативной памяти или процессорного времени) и фиксируя реакцию приложения. Даже 
если у тестировщика будет достаточно квалификации, чтобы самостоятельно выполнить 
подобные операции, ему всё равно понадобится то или иное инструментальное средство — 
так почему не решить эту задачу сразу на уровне автоматизации тестирования? 


Итак, с использованием автоматизации мы получаем возможность увеличить тестовое покры- 
тие(213) за счёт: 


выполнения тест-кейсов, о которых раньше не стоило и думать; 
многократного повторения тест-кейсов с разными входными данными; 
высвобождения времени на создание новых тест-кейсов. 


Но всё ли так хорошо с автоматизацией? Увы, нет. Очень наглядно одну из серьёзных проблем 
можно представить рисунком 3.1.а: 
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Разработка Е = 

2 

m т 


Разработка и отладка 


Выпол- 
нение 


Рисунок 3.1.а — Соотношение времени разработки и выполнения тест-кейсов 
в ручном и автоматизированном тестировании 
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В первую очередь следует осознать, что автоматизация не происходит сама по себе, не суще- 
ствует волшебной кнопки, нажатием которой решаются все проблемы. Более того, с автоматиза- 
цией тестирования связана серия серьёзных недостатков и рисков: 


e Необходимость наличия высококвалифицированного персонала в силу того факта, что 
автоматизация — это «проект внутри проекта» (со своими требованиями, планами, ко- 
дом и т.д.). Даже если забыть на мгновение про «проект внутри проекта», техническая KBA- 
лификация сотрудников, занимающихся автоматизацией, как правило, должна быть ощути- 
мо выше, чем у их коллег, занимающихся ручным тестированием. 

e Разработка и сопровождение как самих автоматизированных тест-кейсов, так и всей необ- 
ходимой инфраструктуры занимает очень много времени. Ситуация усугубляется тем, что в 
некоторых случаях (при серьёзных изменениях в проекте или в случае ошибок в стратегии) 
всю соответствующую работу приходится выполнять заново с нуля: в случае ощутимого из- 
менения требований, смены технологического домена, переработки интерфейсов (как поль- 
зовательских, так и программных) многие тест-кейсы становятся безнадёжно устаревшими 
и требуют создания заново. 

e Автоматизация требует более тщательного планирования и управления рисками, т. к. в про- 
тивном случае проекту может быть нанесён серьёзный ущерб (см. предыдущий пункт про 
переделку с нуля всех наработок). 

e Коммерческие средства автоматизации стоят ощутимо дорого, а имеющиеся бесплатные 
аналоги не всегда позволяют эффективно решать поставленные задачи. И здесь мы снова 
вынуждены вернуться к вопросу ошибок в планировании: если изначально набор техно- 
логий и средств автоматизации был выбран неверно, придётся не только переделывать всю 
работу, но и покупать новые средства автоматизации. 

e Средств автоматизации крайне много, что усложняет проблему выбора того или иного сред- 
ства, затрудняет планирование и определение стратегии тестирования, может повлечь за 
собой дополнительные временные и финансовые затраты, а также необходимость обучения 
персонала или найма соответствующих специалистов. 


Итак, автоматизация тестирования требует ощутимых инвестиций и сильно повышает про- 
ектные риски, а потому существуют специальные подходы36°, 366, 367, 368 по оценке примени- 
мости и эффективности автоматизированного тестирования. Если выразить всю их суть очень 
кратко, то в первую очередь следует учесть: 


e Затраты времени на ручное выполнение тест-кейсов и на выполнение этих же тест-кейсов, 
но уже автоматизированных. Чем ощутимее разница, тем более выгодной представляется 
автоматизация. 

• Количество повторений выполнения одних и тех же тест-кейсов. Чем оно больше, тем боль- 
ше времени мы сможем сэкономить за счёт автоматизации. 

e Затраты времени на отладку, обновление и поддержку автоматизированных тест-кейсов. 
Этот параметр сложнее всего оценить, и именно он представляет наибольшую угрозу успеху 
автоматизации, потому здесь для проведения оценки следует привлекать наиболее опытных 
специалистов. 

• Наличие в команде соответствующих специалистов и их рабочую загрузку. Автоматизацией 
занимаются самые квалифицированные сотрудники, которые в это время не могут решать 
иные задачи. 


365 «Implementing Automated Software Testing — Continuously Track Progress and Adjust Accordingly», Thom Garrett 
[http://www.methodsandtools.com/archive/archive.php?id=94] 

366 «The Return of Investment (ROI) of Test Automation», Stefan Münch and others. [https://www.ispe.org/pe-ja/roi-of- 
test-automation.pdf] 

367 «Ње ROI of Test Automation», Michael Kelly [http://www.sqetraining.com/sites/default/files/articles/ 
XDD8502filelistfilename1_0.pdf] 

368 «Cost Benefits Analysis of Test Automation», Douglas Hoffman [http://www.softwarequalitymethods.com/papers/ 
star99%20model%20paper.pdf] 
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В качестве небольшого примера беглой оценки эффективности автоматизации можно приве- 


сти следующую формулу363: 


N- overall 
A = manual 
effect — м-т" апа analyse , pdevelopment and support, где 
automated automated 


Aeffect — коэффициент выгоды от использования автоматизации, 


N — планируемое количество билдов приложения; 


overall = 
Голата — расчетное время разработки, выполнения и анализа результатов ручного тестиро- 


вания; 


Тч апа analyse _ 
automated — расчетное время выполнения и анализа результатов автоматизированного 


тестирования; 


plevelopment and support _ 
automated — расчетное время разработки и сопровождения автоматизирован- 


ного тестирования. 


Чтобы нагляднее представить, как эта формула может помочь, изобразим график коэффици- 
ента выгоды автоматизации в зависимости от количества билдов (рисунок 3.1.5). Допустим, что 
в некотором проекте значения параметров таковы: 


overall М 
Ттапиа! = 30 часов на каждый билд; 
grun and analyse . 
automated = 5 часов на каждый билд; 
plevelopment and support 
automated = 300 часов на весь проект. 
1.4 
1.2 


0.4 


Коэффициент выгоды 
о 
о 


0.2 


1 2 3 4 5 6 т 8 9 10 11 12 13 14 15 
Билд 


Рисунок 3.1.6 — Коэффициент выгоды автоматизации 
в зависимости от количества билдов 


Как видно на рисунке 3.1.Ъ, лишь к 12-му билду автоматизация окупит вложения ис 13-го бил- 
да начнёт приносить пользу. И тем не менее существуют области, в которых автоматизация даёт 
ощутимый эффект почти сразу. Их рассмотрению посвящена следующая глава. 


369 «Introduction to automation», Vitaliy Zhyrytskyy. 
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3.1.2. ОБЛАСТИ ПРИМЕНЕНИЯ 


АВТОМАТИЗАЦИИ 


Сначала мы ещё раз посмотрим на список задач, решить которые помогает автоматизация: 

• Выполнение тест-кейсов, непосильных человеку. 

• Решение рутинных задач. 

• Ускорение выполнения тестирования. 

• Высвобождение человеческих ресурсов для интеллектуальной работы. 

• Увеличение тестового покрытия. 

• Улучшение кода за счёт увеличения тестового покрытия и применения специальных техник 


автоматизации. 


Эти задачи чаще всего встречаются и проще всего решаются в следующих случаях (см. таб- 


лицу 3.1.а). 


Таблица 3.1.а — Случаи наибольшей применимости автоматизации 


Случай / задача 


Какую проблему решает автоматизация 


Регрессионное тестиро- 
gannet’), 


Необходимость выполнять вручную тесты, количество которых HEY- 
клонно растёт с каждым билдом, но вся суть которых сводится к про- 
верке того факта, что ранее работавшая функциональность продол- 
жает работать корректно. 


Инсталляционное тес- 
тирование!88} и на- 
стройка тестового окру- 
жения. 


Множество часто повторяющихся рутинных операций по проверке 
работы инсталлятора, размещения файлов в файловой системе, содер- 
жимого конфигурационных файлов, реестра и т.д. Подготовка прило- 
жения в заданной среде и с заданными настройками для проведения 
основного тестирования. 


Конфигурационное тес- 
тирование?1} и rec- 
тирование совмести- 
мости l, 


Выполнение одних и тех же тест-кейсов на большом множестве вход- 
ных данных, под разными платформами и в разных условиях. Клас- 
сический пример: есть файл настроек, в нём сто параметров, каждый 
может принимать сто значений: существует 100100 вариантов конфи- 
гурационного файла — все их нужно проверить. 


Использование комби- 
наторных техник тес- 
тирования!109} (в т.ч. 


доменного тестирова- 
нияї97Ъ {241}, 


Генерация комбинаций значений и многократное выполнение 
тест-кейсов с использованием этих сгенерированных комбинаций в 
качестве входных данных. 


Модульное тестирова- 
ние}. 


Проверка корректности работы атомарных участков кода и элемен- 
тарных взаимодействий таких участков кода — практически невыпол- 
нимая для человека задача при условии, что нужно выполнить тысячи 
таких проверок и нигде не ошибиться. 


Интеграционное тести- 
рование!7 7}. 


Глубокая проверка взаимодействия компонентов в ситуации, когда 
человеку почти нечего наблюдать, т. к. все представляющие интерес 
и подвергаемые тестированию процессы проходят на уровнях более 
глубоких, чем пользовательский интерфейс. 
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Таблица 3.1.а [окончание] 


Случай / задача 


Какую проблему решает автоматизация 


Тестирование безопас- 
ности Ц. 


Необходимость проверки прав доступа, паролей по умолчанию, от- 
крытых портов, уязвимостей текущих версий ПО и т.д., т. е. быстрое 
выполнения очень большого количества проверок, в процессе которо- 
го нельзя что-то пропустить, забыть или «не так понять». 


Тестирование произво- 
дительности 3}. 


Создание нагрузки с интенсивностью и точностью, недоступной чело- 
веку. Сбор с высокой скоростью большого набора параметров работы 
приложения. Анализ большого объёма данных из журналов работы 
системы автоматизации. 


Дымовой тест{80} для 
крупных систем. 


Выполнение при получении каждого билда большого количества до- 
статочно простых для автоматизации тест-кейсов. 


Приложения (или их 
части) без графического 
интерфейса. 


Проверка консольных приложений на больших наборах значений па- 
раметров командной строки (и их комбинаций). Проверка приложе- 
ний и их компонентов, вообще не предназначенных для взаимодей- 
ствия с человеком (веб-сервисы, серверы, библиотеки и т. д.) 


Длительные, рутинные, 
утомительные для чело- 
века и/или требующие 
повышенного внима- 
ния операции. 


Проверки, требующие сравнения больших объёмов данных, высокой 
точности вычислений, обработки большого количества размещённых 
по всему дереву каталогов файлов, ощутимо большого времени вы- 
полнения и т.д. Особенно, когда такие проверки повторяются очень 
часто. 


Проверка «внутренней 
функциональности» 
веб-приложений (ссы- 
лок, доступности стра- 
ници Т.д.) 


Автоматизация предельно рутинных действий (например, проверить 
все 30’000+ ссылок на предмет того, что все они ведут на реально CY- 
ществующие страницы). Автоматизация здесь упрощается в силу 
стандартности задачи — существует много готовых решений. 


Стандартная, однотип- 
ная для многих проек- 
тов функциональность. 


«Технические задачи». 


Даже высокая сложность при первичной автоматизации в таком слу- 
чае окупится за счёт простоты многократного использования полу- 
ченных решений в разных проектах. 


Проверки корректности протоколирования, работы с базами данных, 
корректности поиска, файловых операций, корректности форматов и 
содержимого генерируемых документов и т. д. 


С другой стороны, существуют случаи, в которых автоматизация, скорее всего, приведёт толь- 
ко к ухудшению ситуации. Вкратце — это все те области, где требуется человеческое мышление, 
а также некоторый перечень технологических областей. 

Чуть более подробно список выглядит так (таблица 3.1.b): 


Таблица 3.1.6 — Случаи наименьшей применимости автоматизации 


Случай / задача 


В чём проблема автоматизации 


Планирование!206). 


Разработка тест-кейсов(122). 


Написание отчётов о дефектах 71. 


Компьютер пока не научился думать. 


отчётность 206}. 


Анализ результатов тестирования и 
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Таблица 3.1.6 [окончание] 


Случай / задача 


В чём проблема автоматизации 


Функциональность, которую нужно (до- 
статочно) проверить всего несколько раз. 


Тест-кейсы, которые нужно выполнить 
всего несколько раз (если человек может 
их выполнить). 


Затраты на автоматизацию не окупятся. 


Низкий уровень абстракции в имеющих- 
ся инструментах автоматизации. 


Придётся писать очень много кода, что не только 
сложно и долго, но и приводит к появлению множе- 
ства ошибок в самих тест-кейсах. 


Слабые возможности средства автома- 
тизации по протоколированию процесса 
тестирования и сбору технических дан- 
ных о приложении и окружении. 


Есть риск получить данные в виде «что-то где-то CHO- 
малось», что не помогает в диагностике проблемы. 


Низкая стабильность требований. 


Сложные комбинации большого количе- 
ства технологий. 


Придётся очень многое переделывать, что в случае 
автоматизации обходится дороже, чем в случае руч- 


ного тестирования. 


Высокая сложность автоматизации, низкая надёж- 
ность тест-кейсов, высокая сложность оценки тру- 
дозатрат и прогнозирования рисков. 


Проблемы с планированием и ручным 
тестированием. 


Автоматизация хаоса приводит к появлению авто- 
матизированного хаоса, но при этом ещё и требует 
трудозатрат. Сначала стоит решить имеющиеся про- 
блемы, а потом включаться в автоматизацию. 


Нехватка времени и угроза срыва сроков 


Автоматизация не приносит мгновенных резуль- 
татов. Поначалу она лишь потребляет ресурсы ко- 
манды (в том числе время). Также есть универсаль- 
ный афоризм: «лучше руками протестировать хоть 
что-то, чем автоматизированно протестировать ни- 
чего». 


Области тестирования, требующие оцен- 
ки ситуации человеком (тестирование 
удобства использования}, тестирова- 
ние доступности 9} и т.д.) 


В принципе, можно разработать некие алгоритмы, 
оценивающие ситуацию так, как её мог бы оценить 
человек. Но на практике живой человек может сде- 
лать это быстрее, проще, надёжнее и дешевле. 


Вывод: СТОИТ ПОМНИТЬ, ЧТО эффект отавтоматизации наступает не сразу и не всегда. Как и лю- 
бой дорогостоящий инструмент, автоматизация при верном применении может дать ощутимую 
выгоду, но при неверном принесёт лишь весьма ощутимые затраты. 
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ОСОБЕННОСТИ 
АВТОМАТИЗИРОВАННОГО 
ТЕСТИРОВАНИЯ 


3.2.1. НЕОБХОДИМЫЕ ЗНАНИЯ 
И НАВЫКИ NEm 


Во множестве источников, посвящённых основам автоматизации тестирования, можно встре- 
тить схемы наподобие представленной на рисунке 3.2.а — то есть автоматизация тестирования 
представляет собой сочетание программирования и тестирования в разных масштабах (в зави- 
симости от проекта и конкретных задач). 


Програм- 
мирование 


Тестиро- 
вание 


Автоматизация 
тестирования 


Програм- 
мирование 


Тестиро- 
вание 


Рисунок 3.2.а — Сочетание программирования и тестирования 
в автоматизации тестирования 


Отсюда следует простой вывод, что специалист по автоматизации тестирования должен соче- 
тать в себе навыки и умения как программиста, так и тестировщика. Но этим перечень не закан- 
чивается: умение администрировать операционные системы, сети, различные серверы, умение 
работать с базами данных, понимание мобильных платформ и т.д. — всё это может пригодиться. 

Но даже если остановиться только на навыках программирования и тестирования, в автома- 
тизации тоже есть свои особенности — набор технологий. В классическом ручном тестировании 
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развитие происходит постепенно и эволюционно — проходят годы и даже десятилетия между 
появлением новых подходов, завоёвывающих популярность. В программировании прогресс 
идёт чуть быстрее, но и там специалистов выручает согласованность и схожесть технологий. 

В автоматизации тестирования ситуация выглядит иначе: десятки и сотни технологий и под- 
ходов (как заимствованных из смежных дисциплин, так и уникальных) появляются и исчезают 
очень стремительно. Количество инструментальных средств автоматизации тестирования уже 
исчисляется тысячами и продолжает неуклонно расти. 

Потому к списку навыков программирования и тестирования можно смело добавить крайне 
высокую обучаемость и способность в предельно сжатые сроки самостоятельно найти, изучить, 
понять и начать применять на практике совершенно новую информацию из, возможно, ранее 
абсолютно незнакомой области. Звучит немного пугающе, но одно можно гарантировать: скучно 
не будет точно. 

О нескольких наиболее распространённых технологиях мы поговорим в главе «Технологии 
автоматизации тестирования»{270}. 
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3.2.2. ОСОБЕННОСТИ ТЕСТ-КЕЙСОВ 
В АВТОМАТИЗАЦИИ имея 


Часто (а в некоторых проектах и «как правило») автоматизации подвергаются тест-кейсы, из- 
начально написанные простым человеческим языком (м, В принципе, пригодные для выполне- 
ния вручную) — т.е. обычные классические тест-кейсы, которые мы уже рассматривали подроб- 
но в соответствующей главе!22}. 

И всё же есть несколько важных моментов, которые стоит учитывать при разработке (или до- 
работке) тест-кейсов, предназначенных для дальнейшей автоматизации. 

Главная проблема состоит в том, что компьютер — это не человек, и соответствующие тест-кей- 
сы не могут оперировать «интуитивно понятными описаниями», а специалисты по автоматиза- 
ции совершенно справедливо не хотят тратить время на то, чтобы дополнить такие тест-кейсы 
необходимыми для выполнения автоматизации техническими подробностями, = y них хватает 
собственных задач. 

Отсюда следует список рекомендаций по подготовке тест-кейсов к автоматизации и непосред- 
ственно самой автоматизации: 


e Ожидаемый результат в автоматизированных тест-кейсах должен быть описан предельно 
чётко с указанием конкретных признаков его корректности. Сравните: 


Плохо Хорошо 


7. Загружается стандартная страница поиска. |7.Загружается страница поиска: title = 
«Search page», присутствует форма с поля- 
ми «input їуре=”їехї”»‚ «input type=“submit” 
уаше=“Со!”», присутствует логотип «logo. 
jpg» и отсутствуют иные графические эле- 
менты («img»). 


• Поскольку тест-кейс может быть автоматизирован с использованием различных инстру- 
ментальных средств, следует описывать его, избегая специфических для того или иного ин- 
струментального средства решений. Сравните: 


Плохо Хорошо 


1. Кликнуть по ссылке «Search». 1. Кликнуть по ссылке «Search». 
2. Использовать clickAndWait для синхрониза- |2. Дождаться завершения загрузки страницы. 
ции тайминга. 


• В продолжение предыдущего пункта: тест-кейс может быть автоматизирован для выполне- 
ния под разными аппаратными и программными платформами, потому не стоит изначаль- 
но прописывать в него что-то, характерное лишь для одной платформы. Сравните: 


Плохо Хорошо 


8. Отправить приложению сообщение \М/М_ |8. Передать фокус ввода любому из не свёрну- 
СЫСК в любое из видимых окон. тых окон приложения (если таких нет — раз- 
вернуть любое из окон). 

9. Проэмулировать событие «клик левой кноп- 
кой мыши» для активного окна. 


Одной из неожиданно проявляющихся проблем до сих пор является синхронизация средства 
автоматизации и тестируемого приложения по времени: в случаях, когда для человека ситуация 
является понятной, средство автоматизации тестирования может среагировать неверно, «не до- 
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ждавшись» определённого состояния тестируемого приложения. Это приводит к завершению 
неудачей тест-кейсов на корректно работающем приложении. Сравните: 


Плохо 


Хорошо 


1. Кликнуть по ссылке «Expand data». 


«Unknown». 


2. Выбрать из появившегося списка значение 


1. Кликнуть по ссылке «Expand data». 

2. Дождаться завершения загрузки данных в 
список «Extended data» (select id=”extended_ 
data’): список перейдёт в состояние enabled. 

3. Выбрать в списке «Extended data» значение 
«Unknown». 


e Нестоит искушать специалиста по автомат 


изации на вписывание в код тест-кейса констант- 


ных значений (T.H. «хардкодинг»). Если вы можете понятно описать словами значение и/или 
смысл некоей переменной, сделайте это. Сравните: 


Плохо 


Хорошо 


1. Открыть http://application/. 


1. Открыть главную страницу приложения. 


e По возможности следует использовать наиболее универсальные способы взаимодействия с 


тестируемым приложением. Это значитель 
чае, если изменится набор технологий, с по 
ните: 


но сократит время поддержки тест-кейсов в слу- 
мощью которых реализовано приложение. Срав- 


Плохо 


Хорошо 


8. Передать в поле «Search» набор событий 
WM_KEY_DOWN, {знак}, WM_KEY_UP, 
в результате чего в поле должен быть введён 
поисковый запрос. 


8. Проэмулировать ввод значения поля 
«Search» с клавиатуры (не годится вставка 
значения из буфера или прямое присваива- 
ние значения!). 


e Автоматизированные тест-кейсы должны быть независимыми. Из любого правила бывают 
исключения, но в абсолютном большинстве случаев следует предполагать, что мы не знаем, 
какие тест-кейсы будут выполнены до и после нашего тест-кейса. Сравните: 


Плохо 


Хорошо 


1. Из файла, созданного предыдущим тестом... 


1. Перевести чек-бокс «Use stream buffer file» в 
состояние checked. 

2. Активировать процесс передачи данных 
(кликнуть по кнопке «${агї»). 

3. Из файла буферизации прочитать... 


e Стоит ПОМНИТЬ, ЧТО автоматизированный тест-кейс — это программа, и стоит учитывать 


хорошие практики программирования хотя бы на уровне отсутствия т.н. «магических зна- 
чений», «хардкодинга» и тому подобного. Сравните: 


Плохо 


Хорошо 


if ($date_value == ‘2015.06.18') 


| 


«Магическое 


значение» 


if ($status = 42) 


Ошибка в выражении 


(= вместо == 


if ($date_value == date(‘Y.m.ď’)) 


Актуальные данные 


Осмысленная 
константа 


Ошибка исправлена, к тому же 


константа в сравнении находится 
слева от переменной 
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e Стоит внимательно изучать документацию по используемому средству автоматизации, YTO- 
бы избежать ситуации, когда из-за неверно выбранной команды тест-кейс становится лож- 
но положительным, т.е. успешно проходит в ситуации, когда приложение работает неверно. 


бывает в автоматизации тестирования: они вселяют в проектную команду ложную уве- 
ренность в том, что приложение работает корректно, т.е. фактически прячут дефекты, 
вместо того, чтобы обнаруживать их. 


@ Так называемые ложно положительные тест-кейсы — едва ли не самое страшное, что 


Поскольку для многих начинающих тестировщиков первым учебным средством автоматиза- 
ции тестирования является Selenium ТРЕ?З70, приведём пример с его использованием. Допустим, 
в некотором шаге тест-кейса нужно было проверить, что чек-бокс с id=cb выбран (checked). 
По какой-то причине тестировщик выбрал неверную команду, и сейчас на этом шаге проверятся, 
что чек-бокс позволяет изменять своё состояние (enabled, editable), а не что он выбран. 


Плохо (неверная команда) Хорошо (верная команда) 


verifyEditable |id=cb verifyChecked |id=cb 


e И напоследок рассмотрим ошибку, которую по какой-то мистической причине совершает 
добрая половина начинающих автоматизаторов — это замена проверки действием и наобо- 
рот. Например, вместо проверки значения поля они изменяют значение. Или вместо изме- 
нения состояния чек-бокса проверяют его состояние. Здесь не будет примеров на «плохо/ 
хорошо», т. к. хорошего варианта здесь нет — такого просто не должно быть, т.к. это — гру- 
бейшая ошибка. 


Кратко подытожив рассмотренное, отметим, что тест-кейс, предназначенный для автомати- 
зации, будет куда более похож на миниатюрное техническое задание по разработке небольшой 
программы, чем на описание корректного поведения тестируемого приложения, понятное чело- 
веку. 


И ещё одна особенность автоматизированных тест-кейсов заслуживает отдельного рассмотре- 
ния — это источники данных и способы их генерации. Для выполняемых вручную тест-кейсов 
эта проблема не столь актуальна, т.к. при выполнении 3-5-10 раз мы также вручную вполне 
можем подготовить нужное количество вариантов входных данных. Но если мы планируем вы- 
полнить тест-кейс 50-100-500 раз с разными входными данными, вручную столько данных мы 
не подготовим. Источниками данных в такой ситуации могут стать: 


• Случайные величины: случайные числа, случайные символы, случайные элементы из HEKO- 
торого набора и т.д. 

• Генерация (случайных) данных по алгоритму: случайные числа в заданном диапазоне, стро- 
ки случайной длины из заданного диапазона из случайных символов из определённого на- 
бора (например, строка длиной от 10 до 100 символов, состоящая только из букв), файлы с 
увеличивающимся по некоему правилу размером (например, 10 КБ, 100 КБ, 1000 КБ ит.д.). 

• Получение данных из внешних источников: извлечение данных из базы данных, обращение 
к некоему веб-сервису и т.д. 

• Собранные рабочие данные, т.е. данные, созданные реальными пользователями в процессе 
их реальной работы (например, если бы мы захотели разработать собственный текстовый 


370 Selenium ТРЕ. [http://docs.seleniumhq.org/projects/ide/] 
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редактор, тысячи имеющихся у нас и наших коллег 4ос(х)-файлов были бы такими рабочи- 
ми данными, на которых мы бы проводили тестирование). 

e Ручная генерация — да, она актуальная и для автоматизированных тест-кейсов. Например, 
вручную создать по десять (да даже и по 50-100) корректных и некорректных е-па!-адресов 
получится куда быстрее, чем писать алгоритм их генерации. 


Применение некоторых из этих идей по генерации данных мы рассмотрим подробнее в следу- 
ющей главе. 
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3.2.3. ТЕХНОЛОГИИ АВТОМАТИЗАЦИИ 


ТЕСТИРОВАНИЯ 


В данной главе мы рассмотрим несколько высокоуровневых технологий автоматизации тести- 


рования, каждая из которых, в свою очередь, базируется на своём наборе технических решений 


(инструментальных средствах, языках программирования, способах взаимодействия с тести- 


руемым приложением и т.д.) 


Начнём с краткого обзора эволюции высокоуровневых технологий, при этом подчеркнув, что 


«старые» решения по-прежнему используются (или как компоненты «новых», или самостоятель- 
у 


но в отдельных случаях). 


Таблица 3.2.а — Эволюция высокоуровневых технологий автоматизации тестирования 


№ | Подход Суть Преимущества Недостатки 
1 | Частные решения. |Для решения каждой | Быстро, просто. Нет системности, мно- 
отдельной задачи пи- го времени уходит на 
шется отдельная про- поддержку. Почти не- 
грамма. возможно повторное 
использование. 

2 | Тестирование под|Из тест-кейса вовне | Один и тот же тест-|Логика тест-кейса 
управлением дан-|выносятся входные | кейс можно повторять | по-прежнему строго 
ными} (DDT). данные и ожидаемые | многократно с разны- | определяется внутри, 

результаты. ми данными. а потому для её изме- 
нения тест-кейс надо 
переписывать. 

3 |Тестирование под | Из тест-кейса вовне Концентрация на вы- | Сложность выполне- 
управлением клю- | выносится описание |сокоуровневых дей-|ния низкоуровневых 
чевыми слова- |его поведения. ствиях. Данные и операций. 
ми} (КОТ). особенности поведе- 

ния хранятся вовне и 
могут быть изменены 
без изменения кода 
тест-кейса. 

4 |Использование| Конструктор, позво- | Мощность и гибкость. | Относительная слож- 
фреймворков. ляющий использовать ность (особенно — 

остальные подходы. в создании фрейм- 
ворка). 

5 | Запись и воспроиз- | Средство автоматиза- | Простота, высокая|Крайне низкое Ka- 
ведение (Record &|ции записывает дей- скорость создания | чество, линейность, 
Playback). ствия тестировщика и тест-кейсов. неподдерживаемость 

может воспроизвести тест-кейсов. Требуется 
их, управляя тестируе- серьёзная доработка 
мым приложением. полученного кода. 
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Таблица 3.2.а [окончание] 
№ | Подход Суть Преимущества Недостатки 
6 | Тестирование под Развитие идей тести- | Высокое удобство про-| Такие тест-кейсы 


управлением пове- 
дением!5) (ВОТ). 


рования под управ- 
лением данными и 
ключевыми словами. 
Отличие — в концен- 
трации на бизнес-сце- 
нариях без выполне- 
ния мелких проверок. 


верки высокоуровне- 
вых пользовательских 
сценариев. 


пропускают большое 
количество функцио- 
нальных и нефункци- 
ональных дефектов, а 
потому должны быть 
дополнены классиче- 
скими более низко- 


уровневыми тест-кей- 
сами. 


На текущем этапе развития тестирования представленные в таблице 3.2.а технологии иерар- 
хически можно изобразить следующей схемой (см. рисунок 3.2.6): 


Тестирование под управлением 
поведением 
Комбинация тестирование под управлением 
данными и ключевыми словами 
Тестирование под управлением 
ключевыми словами 


Тестирование под 
управлением данными 
Запись и 


воспроизведение 
Использование 
фреймворков 


Рисунок 3.2.6 — Иерархия технологий автоматизации тестирования 


Сейчас мы рассмотрим эти технологии подробнее и на примерах, но сначала стоит упомянуть 
один основополагающий подход, который находит применение практически в любой технологии 
автоматизации, — функциональную декомпозицию. 


ФУНКЦИОНАЛЬНАЯ ДЕКОМПОЗИЦИЯ 


Функциональная декомпозиция (functional decomposition???) — процесс определения 
функции через её разделение на несколько низкоуровневых подфункций. 


Функциональная декомпозиция активно используется как в программировании, так и в авто- 
матизации тестирования с целью упрощения решения поставленных задач и получения возмож- 
ности повторного использования фрагментов кода для решения различных высокоуровневых 
задач. 


371 Functional decomposition. The process of defining lower-level functions and sequencing relationships. [«System 
Engineering Fundamentals», Defense Acquisition University Press] 
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Произвести 
авторизацию 


Ввести имя Отправить Проверить 


Ввести пароль 


пользователя данные результат 


Рисунок 3.2.с — Пример функциональной декомпозиции в программировании и тестировании 


Рассмотрим пример (рисунок 3.2.с): легко заметить, что часть низкоуровневых действий 
(поиск и заполнение полей, поиск и нажатие кнопок) универсальна и может быть использована 
при решении других задач (например, регистрация, оформление заказа и т.д.). 

Применение функциональной декомпозиции позволяет не только упростить процесс реше- 
ния поставленных задач, но и избавиться от необходимости самостоятельной реализации дей- 
ствий на самом низком уровне, т.к. они, как правило, уже решены авторами соответствующих 
библиотек или фреймворков. 


Возвращаемся к технологиям автоматизации тестирования. 


ЧАСТНЫЕ РЕШЕНИЯ 


Иногда перед тестировщиком возникает уникальная (в том плане, что такой больше не бу- 
дет) задача, для решения которой нет необходимости использовать мощные инструментальные 
средства, а достаточно написать небольшую программу на любом из высокоуровневых языков 
программирования (Java, С#, РНР ит.д.) или даже воспользоваться возможностями командных 
файлов операционной системы или подобными тривиальными решениями. 

Ярчайшим примером такой задачи и её решения является автоматизация дымового тестиро- 
вания нашего «Конвертера файлов» (код командных файлов для Windows и Linux приведён в 
соответствующем приложении!286}). Также сюда можно отнести задачи вида: 


• Подготовить базу данных, наполнив её тестовыми данными (например, добавить в систему 
миллион пользователей со случайными именами). 

• Подготовить файловую систему (например, создать структуру каталогов и набор файлов для 
выполнения тест-кейсов). 


• Перезапустить набор серверов и/или привести их в требуемое состояние. 


Удобство частных решений состоит в том, что их можно реализовать быстро, просто, «вот 
прямо сейчас». Но у них есть и огромный недостаток — это «кустарные решения», которыми 
может воспользоваться всего пара человек. И при появлении новой задачи, даже очень похожей 
на ранее решённую, скорее всего, придётся всё автоматизировать заново. 

Более подробно преимущества и недостатки частных решений в автоматизации тестирования 
показаны в таблице 3.2.5. 


3.2. ОСОБЕННОСТИ АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ 
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Таблица 3.2.6 — Преимущества и недостатки частных решений 
в автоматизации тестирования 


Преимущества 


Недостатки 


Быстрота и простота реализации. 
Возможность использования любых доступ- 
ных инструментов, которыми тестировщик 
умеет пользоваться. 

Эффект от использования наступает неза- 
медлительно. 

Возможность нахождения очень эффектив- 
ных решений в случае, когда основные ин- 
струменты, используемые на проекте для 
автоматизации тестирования, оказываются 
малопригодными для выполнения данной 
отдельной задачи. 

Возможность быстрого создания и оценки 
прототипов перед применением более тяже- 


Отсутствие универсальности и, как след- 
ствие, невозможность или крайняя слож- 
ность повторного использования (адапта- 
ции для решения других задач). 
Разрозненность и несогласованность реше- 
ний между собой (разные подходы, техноло- 
гии, инструменты, принципы решения). 
Крайне высокая сложность развития, под- 
держки и сопровождения таких решений 
(чаще всего, кроме самого автора никто во- 
обще не понимает, что и зачем было сделано, 
и как оно работает). 

Является признаком «кустарного производ- 
ства», не приветствуется в промышленной 


ловесных решений. 


разработке программ. 


ТЕСТИРОВАНИЕ ПОД УПРАВЛЕНИЕМ ДАННЫМИ (ОРТ) 


Обратите внимание, как много раз в командных файлах 86} повторяются строки, выпол- 
няющие одно и то же действие над набором файлов (и нам ещё повезло, что файлов немного). 
Ведь куда логичнее было бы каким-то образом подготовить список файлов и просто передать 
его на обработку. Это и будет тестированием под управлением данными. В качестве примера 
приведём небольшой скрипт на РНР, который читает С$У-файл с тестовыми данными (именами 
сравниваемых файлов) и выполняет сравнение файлов. 


function compare 1156 оЕЁ files ($file міёһ сзу Чафа) 
{ 
$data = file ($#1е міёһ сзу даба); 
foreach ($data аз $line) 
{ 
$parsed = str csv ($line); 
if (md5_file($parsed[0]) === md5_file($parsed[1])) { 
file_put_contents ('smoke_test.log', 
"OK! File 
} else { 


'".брагзеа[0]."' was processed correctly!\n"); 


file _put_contents ('smoke_test.log', 
'ERROR! File '".5$рагзеа[0]."' was NOT 
processed correctly!\n"); 


Пример СЅУ-файла (первые две строки): 


ТезЕ ЕТАГОМ/ «Мелкий» эталон М1М1251.6хе,ООТ/«Мелкий» файл 
ТезЕ ЕТАГОМ/«Средний» эталон СР866.ЕхЕ,ОПТ/«Средний» файл 


в WIN1251.txt 
СР866. Е хе 


Теперь нам достаточно подготовить С$У-файл с любым количеством имён сравниваемых фай- 
лов, а код тест-кейса не увеличится ни на байт. 
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К другим типичным примерам использования тестирования под управлением данными отно- 


сится: 


• Проверка авторизации и прав доступа на большом наборе имён пользователей и паролей. 

e Многократное заполнение полей форм разными данными и проверка реакции приложения. 

. Выполнение тест-кейса на основе данных, полученных с помощью комбинаторных техник 
(пример таких данных представлен в соответствующем приложении{301). 


Данные для рассматриваемого подхода к организации тест-кейсов могут поступать из фай- 


ЛОВ, баз данных и иных внешних источников или даже генерироваться в процессе выполнения 


тест-кейса (см. описание источников данных для автоматизированного тестирования!268}). 
Преимущества и недостатки тестирования под управлением данными показаны в табли- 


це 3.2.с. 


Таблица 3.2.с — Преимущества и недостатки тестирования под управлением данными 


Преимущества 


Недостатки 


Устранение избыточности кода тест-кейсов. 
Удобное хранение и понятный человеку фор- 
мат данных. 

Возможность поручения генерации данных 
сотруднику, не имеющему навыков програм- 
мирования. 

Возможность использования одного и того 
же набора данных для выполнения разных 
тест-кейсов. 

Возможность повторного использования на- 
бора данных для решения новых задач. 
Возможность использования одного и 
того же набора данных в одном и том же 
тест-кейсе, но реализованном под разными 
платформами. 


При изменении логики поведения тест-кейса 
его код всё равно придётся переписывать. 
При неудачно выбранном формате представ- 
ления данных резко снижается их понят- 
ность для неподготовленного специалиста. 
Необходимость использования технологий 
генерации данных. 

Высокая сложность кода тест-кейса в случае 
сложных неоднородных данных. 

Риск неверной работы тест-кейсов в случае, 
когда несколько тест-кейсов работают с од- 
ним и тем же набором данных, и он был из- 
менён таким образом, на который не были 
рассчитаны некоторые тест-кейсы. 

Слабые возможности по сбору данных в слу- 
чае обнаружения дефектов. 

Качество тест-кейса зависит от профессио- 
нализма сотрудника, реализующего код 
тест-кейса. 


ТЕСТИРОВАНИЕ ПОД УПРАВЛЕНИЕМ КЛЮЧЕВЫМИ СЛОВАМИ 


Логическим развитием идеи о вынесении вовне тест-кейса данных является вынесение вовне 


тест-кейса команд (описания действий). Разовьём только что показанный пример, добавив в 
СЅУ-файл ключевые слова, являющиеся описанием выполняемой проверки: 


e moved — файл отсутствует в каталоге-источнике и присутствует в каталоге-приёмнике; 
e intact — файл присутствует в каталоге-источнике и отсутствует в каталоге-приёмнике; 


e equals — содержимое файлов идентично. 


function execute_test ($ѕсепагіо) 


$data = file ($scenario); 
foreach ($data as $line) 
{ 
$рагѕеа = str csv ($line); 
switch ($parsed[0]) 
{ 
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// Проверка перемещения файла 


case 'moved': 
if (is_file($parsed[1]))&&(!is_file($parsed[2])) { 
file_put_contents ('smoke_test.log', 


"ОК! '".5рагзеа[0]."' file was processed!\n"); 
} else { 

file_put_contents ('smoke_test.log', 

"ERROR! '".брагзеа[0]."' file was 


NOT processed!\n"); 
} 


break; 


// Проверка отсутствия перемещения файла 
сазе 'intact': 


if (!15 Не ($рагѕеа[1])) || (15 #1е($рагѕеа[2])) { 
file_put_contents ('smoke_test.log', 
"OK! '".5брагзеа[0]."' file was processed!\n"); 
} else { 
file_put_contents ('smoke_test.log', 
"ERROR! '".5рагзеа[0]."' file was 


NOT processed!\n"); 


} 
break; 


// Сравнение файлов 
сазе 'equals'!': 


if (ма5 Не ($рагѕеа[1]) === та5 Не ($рагзеа[2])) { 
Не риё сопіепіѕ ('smoke_test.log', 
"ОК! File '".$рагвеа[0]."' Маз 
processed correctly!\n"); 
} else { 
file_put_contents ('smoke_test.log', 
"ERROR! File '".брагзеа[0]."' Was 


NOT processed correctly!\n"); 


Пример С5У-файла (первые пять строк): 
поуеа, ТМ/«Мелкий» эталон И1М1251.6хЕ, ООТ/«Мелкий» файл 
moved, ТМ/«Средний» эталон СР866.ЕхЕ,ОПТ/«Средний» файл СР866.ЕхЕ 


intact, ІМ/Картинка.јрдо, О0Т/Картинка.јрд 
‚ОМ/ «Мелкий» эталон ИІМ1251.ёхі,ООТ/«Мелкий» файл в М1М1251. 


в WIN1251.txt 


equals, Теѕі ЕТА 
txt 
equals, Test ЕТА 


ОМ/«Средний» эталон СР866.іхі,О0ОТ/«Средний» файл СР866.іхі 


Ярчайшим примером инструментального средства автоматизации тестирования, идеально 
следующего идеологии тестирования под управлением ключевыми словами, является Selenium 
ГРЕЗ70, в котором каждая операция тест-кейса описывается в виде: 


Действие (ключевое слово) Необязательный параметр 1 |Необязательный параметр 2 
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Тестирование под управлением ключевыми словами стало тем переломным моментом, начи- 
ная с которого стало возможным привлечение к автоматизации тестирования нетехнических 
специалистов. Согласитесь, что нет необходимости в знаниях программирования и тому подоб- 
ных технологий, чтобы наполнять подобные только что показанному СЅУ-файлы или (что очень 
часто практикуется) ХІЅХ-файлы. 

Вторым естественным преимуществом тестирования под управлением ключевыми словами 
(хотя она вполне характерна и для тестирования под управлением данными) стала возможность 
использования различных инструментов одними и теми же наборами команд и данных. Так, на- 
пример, ничто не мешает нам взять показанные С5У-файлы и написать новую логику их обра- 
ботки не на РНР, а на С#, Java, Python или даже с использованием специализированных средств 
автоматизации тестирования. 

Преимущества и недостатки тестирования под управлением ключевыми словами показаны в 
таблице 3.2.4. 


Таблица 3.2.4 — Преимущества и недостатки тестирования под управлением 
ключевыми словами 


Преимущества 


Недостатки 


Максимальное устранение избыточности 
кода тест-кейсов. 

Возможность построения мини-фреймвор- 
ков, решающих широкой спектр задач. 
Повышение уровня абстракции тест-кейсов 
и возможность их адаптации для работы с 
разными техническими решениями. 
Удобное хранение и понятный человеку фор- 
мат данных и команд тест-кейса. 
Возможность поручения описания логики 
тест-кейса сотруднику, не имеющему навы- 
ков программирования. 

Возможность повторного использования для 
решения новых задач. 

Расширяемость (возможность добавления 
нового поведения тест-кейса на основе уже 
реализованного поведения). 


Высокая сложность (и, возможно, длитель- 
ность) разработки. 

Высокая вероятность наличия ошибок в коде 
тест-кейса. 

Высокая сложность (или невозможность) 
выполнения низкоуровневых операций, если 
код тест-кейса не поддерживает соответст- 
вующие команды. 

Эффект от использования данного подхода 
наступает далеко не сразу (сначала идёт дли- 
тельный период разработки и отладки самих 
тест-кейсов и вспомогательной функцио- 
нальности). 

Для реализации данного подхода требуется 
наличие высококвалифицированного персо- 
нала. 

Необходимо обучить персонал языку ключе- 
вых слов, используемых в тест-кейсах. 


ИСПОЛЬЗОВАНИЕ ФРЕЙМВОРКОВ 


Фреймворки автоматизации тестирования представляют собой не что иное, как успешно раз- 
вившиеся и ставшие популярными решения, объединяющие В себе лучшие стороны тестирова- 
НИЯ ПОД управлением данными, ключевыми словами и возможности реализации частных реше- 
ний на высоком уровне абстракции. 

Фреймворков автоматизации тестирования очень много, они очень разные, но их объединяет 
несколько общих черт: 


• высокая абстракция кода (нет необходимости описывать каждое элементарное действие) 
с сохранением возможности выполнения низкоуровневых действий; 

• универсальность и переносимость используемых подходов; 

„ достаточно высокое качество реализации (для популярных фреймворков). 
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Как правило, каждый фреймворк специализируется на своём виде тестирования, уровне тес- 
тирования, наборе технологий. Существуют фреймворки для модульного тестирования (напри- 
мер, семейство XUnit), тестирования веб-приложений (например, семейство Selenium), тестиро- 
вания мобильных приложений, тестирования производительности и т.д. 

Существуют бесплатные и платные фреймворки, оформленные в виде библиотек на некото- 
ром языке программирования или в виде привычных приложений с графическим интерфейсом, 
узко- и широко специализированные и т.д. 


сопоставимо со всем текстом данной книги. Но если вам интересно, начните хотя быс 


© К сожалению, подробное описание даже одного фреймворка может по объёму быть 
изучения Selenium МеЬРгіуег372. 


Преимущества и недостатки фреймворков автоматизации тестирования показаны в таб- 
лице 3.2.е. 


Таблица 3.2.е — Преимущества и недостатки фреймворков автоматизации тестирования 


Преимущества Недостатки 
• Широкое распространение. • Требуется время на изучение фреймворка. 
e Универсальность в рамках своего набора |• В случае написания собственного фрейм- 
технологий. ворка де-факто получается новый проект по 


e Хорошая документация и большое сообще-| разработке ПО. 
ство специалистов, с которыми можно про- |® Высокая сложность перехода на другой 


консультироваться. фреймворк. 
• Высокий уровень абстракции. • В случае прекращения поддержки фрейм- 
e Наличие большого набора готовых решений | ворка тест-кейсы рано или поздно придёт- 
и описаний соответствующих лучших прак-| ся переписывать с использованием нового 
тик применения того или иного фреймворка| фреймворка. 
для решения тех или иных задач. e Высокий риск выбора неподходящего 
фреймворка. 


ЗАПИСЬ И ВОСПРОИЗВЕДЕНИЕ (RECORD & PLAYBACK) 


Технология записи и воспроизведения (Record & Playback) стала актуальной с появлением до- 
статочно сложных средств автоматизации, обеспечивающих глубокое взаимодействие с тести- 
руемым приложением и операционной системой. Использование этой технологии, как правило, 
сводится к следующим основным шагам: 


1. Тестировщик вручную выполняет тест-кейс, а средство автоматизации записывает все его 
действия. 

2. Результаты записи представляются в виде кода на высокоуровневом языке программирова- 
ния (в некоторых средствах — специально разработанном). 

3. Тестировщик редактирует полученный код. 

4. Готовый код автоматизированного тест-кейса выполняется для проведения тестирования в 
автоматизированном режиме. 


технология записи и воспроизведения, только применённая для автоматизации реше- 


© Возможно, вам приходилось записывать макросы в офисных приложениях. Это тоже 
ния офисных задач. 


372 Selenium WebDriver Documentation [http://docs.seleniumhq.org/docs/03_webdriver.jsp] 
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Сама технология при достаточно высокой сложности внутренней реализации очень проста 
в использовании и по самой своей сути, потому часто применяется для обучения начинающих 
специалистов по автоматизации тестирования. Её основные преимущества и недостатки пока- 
заны в таблице 3.2.Ё 


Таблица 3.2. — Преимущества и недостатки технологии записи и воспроизведения 


Преимущества 


Недостатки 


Предельная простота освоения (достаточно 
буквально нескольких минут, чтобы начать 
использовать данную технологию). 

Быстрое создание «скелета тест-кейса» за 
счёт записи ключевых действий с тестируе- 
мым приложением. 

Автоматический сбор технических данных 
о тестируемом приложении (идентифика- 
торов и локаторов элементов, надписей, 
имён ит.д.). 

Автоматизация рутинных действий (за- 
полнения полей, нажатий на ссылки, кноп- 
ки ит. д.). 

В отдельных случаях допускает использова- 
ние тестировщиками без навыков програм- 
мирования. 


Линейность тест-кейсов: в записи не будет 
циклов, условий, вызовов функций и прочих 
характерных для программирования и авто- 
матизации явлений. 

Запись лишних действий (как просто оши- 
бочных случайных действий тестировщика с 
тестируемым приложением, так и (во многих 
случаях) переключений на другие приложе- 
ния и работы с ними). 

Так называемый «хардкодинг», т.е. запись 
внутрь кода тест-кейса конкретных значе- 
ний, что потребует ручной доработки для 
перевода тест-кейса на технологию тестиро- 
вания под управлением данными. 
Неудобные имена переменных, неудобное 
оформление кода тест-кейса, отсутствие 
комментариев и прочие недостатки, ус- 
ложняющие поддержку и сопровождение 
тест-кейса в будущем. 

Низкая надёжность самих тест-кейсов в силу 
отсутствия обработки исключений, провер- 
ки условий и т.д. 


Таким образом, технология записи и воспроизведения не является универсальным средством 
на все случаи жизни и не может заменить ручную работу по написанию кода автоматизирован- 
ных тест-кейсов, но в отдельных ситуациях может сильно ускорить решение простых рутинных 
задач. 


ТЕСТИРОВАНИЕ ПОД УПРАВЛЕНИЕМ ПОВЕДЕНИЕМ 


Рассмотренные выше технологии автоматизации максимально сфокусированы на технических 
аспектах поведения приложения и обладают общим недостатком: с их помощью сложно прове- 
рять высокоуровневые пользовательские сценарии (а именно в них и заинтересованы заказчики 
и конечные пользователи). Этот недостаток призвано исправить тестирование под управлением 
поведением, в котором акцент делается не на отдельных технических деталях, а на общей рабо- 
тоспособности приложения при решении типичных пользовательских задач. 

Такой подход не только упрощает выполнение целого класса проверок, но и облегчает взаимо- 
действие между разработчиками, тестировщиками, бизнес-аналитиками и заказчиком, т. к. в OC- 
нове подхода лежит очень простая формула «given-when-then»: 


• Given («имея, предполагая, при условии») описывает начальную ситуацию, в которой нахо- 
дится пользователь в контексте работы с приложением. 

• When («когда») описывает набор действий пользователя в данной ситуации. 

e Then («тогда») описывает ожидаемое поведение приложения. 
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Рассмотрим на примере нашего «Конвертера файлов»: 


• При условии, что приложение запущено. 
• Когда я помещаю во входной каталог файл поддерживаемого размера и формата. 
• Тогда файл перемещается в выходной каталог, а текст внутри файла перекодируется в ОТЕ-8. 


Такой принцип описания проверок позволяет даже участникам проекта, не имеющим глу- 
бокой технической подготовки, принимать участие в разработке и анализе тест-кейсов, а для 
специалистов по автоматизации упрощается создание кода автоматизированных тест-кейсов, 
т.к. такая форма является стандартной, единой и при этом предоставляет достаточно информа- 
ции для написания высокоуровневых тест-кейсов. Существуют специальные технические реше- 
ния (например, Behat, JBehave, МВеБауе, Cucumber), упрощающие реализацию тестирования под 
управлением поведением. 

Преимущества и недостатки тестирования под управлением поведением показаны в таб- 
лице 3.2.5. 


Таблица 3.2.9 — Преимущества и недостатки тестирования под управлением поведением 


Преимущества Недостатки 


e Фокусировка на потребностях конечных 
пользователей. 

• Упрощение сотрудничества между различ- 
ными специалистами. 

e Простота и скорость создания и анализа 
тест-кейсов (что, в свою очередь, повышает 
полезный эффект автоматизации и снижает 
накладные расходы). 


Высокоуровневые поведенческие тест-кейсы 
пропускают много деталей, а потому могут 
не обнаружить часть проблем в приложении 
или не предоставить необходимой для по- 
нимания обнаруженной проблемы инфор- 
мации. 

В некоторых случаях информации, предо- 
ставленной в поведенческом тест-кейсе, не- 
достаточно для его непосредственной авто- 
матизации. 


© 


К классическим технологиям автоматизации тестирования также можно отнести раз- 
работку под управлением тестированием (Test-driven Development, TDD) с её принци- 
пом «красный, зелёный, улучшенный» (Red-Green-Refactor), разработку под управле- 


нием поведением (Behavior-driven Development), модульное тестирование (Unit Testing) 
и т.д. Но эти технологии уже находятся на границе тестирования и разработки прило- 
жений, потому выходят за рамки данной книги. 
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АВТОМАТИЗАЦИЯ 
ВНЕ ПРЯМЫХ ЗАДАЧ 
ТЕСТИРОВАНИЯ 


На протяжении данного раздела мы рассматривали, как автоматизация может помочь в созда- 
нии и выполнении тест-кейсов. Но все те же принципы можно перенести и на остальную работу 
тестировщика, в которой также бывают длительные и утомительные задачи, рутинные задачи 
или задачи, требующие предельного внимания, но не связанные с интеллектуальной работой. 
Всё перечисленное также можно автоматизировать. 

Да, это требует технических знаний и первоначальных затрат сил и времени на реализацию, 
но в перспективе такой подход может экономить до нескольких часов в день. К самым типичным 
решениям из данной области можно отнести: 


e Использование командных файлов для выполнения последовательностей операций — от KO- 
пирования нескольких файлов из разных каталогов до развёртывания тестового окружения. 
Даже в рамках многократно рассмотренных примеров по тестированию «Конвертера фай- 
лов» запуск приложения через командный файл, в котором указаны все необходимые пара- 
метры, избавляет от необходимости вводить их каждый раз вручную. 

• Генерация и оформление данных с использованием возможностей офисных приложений, 
баз данных, небольших программ на высокоуровневых языках программирования. Нет кар- 
тины печальнее, чем тестировщик, руками нумерующий три СОТНИ строк В таблице. 

e Подготовка и оформление технических разделов для отчётов. Можно тратить часы на скру- 
пулёзное вычитывание журналов работы некоего средства автоматизации, а можно один 
раз написать скрипт, который будет за мгновение готовить документ с аккуратными табли- 
цамии графиками, и останется только запускать этот скрипт и прикреплять результаты его 
работы к отчёту. 

• Управление своим рабочим местом: создание и проверка резервных копий, установка об- 
новлений, очистка дисков от устаревших данных и т.д. и т.п. Компьютер всё это может 
(и должен!) делать сам, без участия человека. 

» Сортировка и обработка почты. Даже раскладывание входящей корреспонденции по под- 
папкам гарантированно занимает у вас несколько минут в день. Если предположить, что 
настройка специальных правил в вашем почтовом клиенте сэкономит вам полчаса в неделю, 
за год экономия составит примерно сутки. 

° Виртуализация как способ избавления OT необходимости каждый раз устанавливать и на- 
страивать необходимый набор программ. Если у вас есть несколько заранее подготовлен- 
ных виртуальных машин, их запуск займёт секунды. А в случае необходимости устране- 
ния сбоев разворачивание виртуальной машины из резервной копии заменяет весь процесс 
установки и настройки С нуля операционной системы и всего необходимого программного 
обеспечения. 


Иными словами, автоматизация объективно облегчает жизнь любого ИТ-специалиста, а так- 
же расширяет его кругозор, технические навыки и способствует профессиональному росту. 


Раздел 4: ПРИЛОЖЕНИЯ 


Управление Управление Разработка 
ресурсами проектами решений 
Менеджер Эксперт 
Опытный 
специалист 
Дальнейшее 
развитие и/или 
специализация 


Опыт проектной 
работы 


1. Умение программировать на уровне, 
достаточном для создания автоматизированных 


2. Понимание специфических технологий и 
инструментальных средств, умение выбрать и 
применить их для решения поставленной задачи. 
3. Глубокое понимание принципов работы 


1. Умение планировать, реализовывать и 
оценивать результаты экспериментов. 
2. Умение оптимизировать тесты и тестовые 


3. Умение использовать вспомогательные 
программные средства, используемые проектной 
командой для автоматизации повседневных 


4. Понимание и умение использовать несколько 
высокоуровневых языков программирования, 


Основные навыки: 
Разработка и 
‘адаптация ее 
инструментов эр естон, 
JBehave 
Специальные 
технологии DDT TDD 
программных средств 
Дополнительные навыки: 
тестирование Selenium Android Driver Java 
мобильных CF 
приложений ium К 
р! Selenium iOS Driver =: а 
JavaScript 
Sanum 
Selenium Е 
Web Dever VBScript 
Тестирование веб- задач. 
приложений и веб- ae e d | жрм Ruby 
сервисов к 
й ЗБЕ Scala языков u технологий вёрстки, 
наша || 1968 
ATest 
JScript 
Тестирование. SilkTest | |Testcompiete р! 
настольных XML 
приложений ОТР Autolt 
Р HTML 
WSDL 
TestNG || JUnit 
Модульное SOAP 
тестирование 
pa Моск || NUnit sa 
Инструменты 
автоматизирован- 
ного тестирования 
Тестирование СЕ Е 
производитель- автоматизации a уы бене Программирование 
ности тестирования = е. 


Автоматизация тестирования 


КАРЬЕРА ТЕСТИРОВЩИКА ” 


Дальнейший карьерный рост предполагает либо 
углубление в техническое направление и 
становление экспертом в некоторой области, 
либо переключение в область управления 
проектами или ресурсами. 


После успешного трудоустройства специалист с 
течение нескольких лет повышает свою 
квалификацию, приобретает всё более глубокий и 
обширный опыт, позволяющий как более 
эффективно выполнять свои прямые 
обязанности, так и рассматривать дальнейшие 
перспективы карьерного роста 


Изучение автоматизации тестирования занимает 
от полугода до года. 


Предполагается, что к этому моменту соискатель 
уже изучил функциональное тестирование, а 
также обладает как минимум уверенными 
базовыми знаниями в области 
программирования. Автоматизация тестирования 
подразумевает программирование как часть 
повседневной деятельности. 


Особое внимание на этом этапе подготовки 
уделяется инструментальным средствам и 
специфическим технологиям. 


Бизнес-анализ 


Основы 
программирования 


Оценка трудозатрат —> 


Тестирование веб. 


‘приложений 
o Интернет: 
д технологии 
тестирование 
Базы данных и 
язык SAL 
Отчётность о 
Коммуникативные ЕЕ Использование 
навыки 57 Г | различных ОС 
тестирования 
Методы и Поиски Работа с 
методологии документирование багтрекинговыми 
тестирования дефектов системами 


Виды тестирования 


Разработка тестов — 


Работа с системами 
управления тестами 


Основы Тестирование Работа с системами 
планирования в документациии 3 управления 
тестировании требований требованиями 
Планирование Чтение 
Основы с 
своего рабочего тонов я [| специальной 
времени pos ‘литературы 


Функциональное тестирование 


Основные навыки: 
1. Анализ технической документации 

2. Создание чек-листов. 

3. Разработка тестов и тестовых сценариев. 

4. Поиск и эффективное документирование 
обнаруженных дефектов. 

5. Формирование отдельных фрагментов отчётов 
о результатах тестирования. 

6. Использование вспомогательных 
инструментальных средств. 

7. Понимание методов и видов тестирования, 
умение применять их адекватно ситуации. 


Дополнительные навыки: 

1. Умение вести деловое общение — «вживую», и 
использованием почты и иных средств 
коммуникации 

2. Умение планировать рабочее время и 
оценивать трудозатраты. 

3. Понимание принципов работы компьютерных 
сетей. 

4. Понимание основ баз данных, умение писать 
тривиальные запросы 

5. Умение работать с различными версиями ОС 
семейства Windows и *піх. 


Наступает момент выбора: приступить к работе в 
качестве специалиста по функциональному 
тестированию, переключиться на изучение 
бизнес-анализа или продолжить изучение 
тестирования (в области автоматизации). 


Изучение функционального тестирования 
занимает от полугода до года. 


За это время необходимо приобрести полный 
набор технических и специализированных 
навыков, необходимых специалисту для начала 
работы тестировщиком. 


Поскольку в тестирование приходит много людей 
без достаточной технической подготовки, 
соответствующим темам следует уделять особое 
внимание. 


Работа с офисными 
программами 


Английский язык К 


Формирование 
представления об 
1Т-специализации 


Базовая самоподготовка 


Знания и умения: 
1. Свободное владение Word, Excel. 

2. Свободное владение компьютером на уровне 
уверенного пользователя (умение устанавливать 
и настраивать ОС, сеть, необходимое ПО). 

3. Сформированное представление о работе 
тестировщика, желание заниматься именно этой 
работой. 

4. Знание английского на уровне беглого чтения 
англоязычной документации. 


Базовая самоподготовка может занимать разное 
время. В общем случае ей рекомендуется. 
посвятить первые 2-3 курса университета. 


Успешная базовая самоподготовка позволяет 
пройти отбор на тренинг и усвоить программу 
тренинга. 
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Задание 


@ КОММЕНТАРИИ К ЗАДАНИЯМ 


Комментарий 


1.1.а49) 


Ответ: около 2е+42 лет, т.е. примерно в 1.66е+32 раза больше, чем текущий возраст 
Вселенной. 

Решение: (264 * 264 * 264) / (100°000°000 * 31536000примерно секунд в году) = 
1.9904559029003934436313386045179е+42 лет. 


1.1.5410} 


1.2.а112) 


Для знакомства с широчайшим спектром терминологии тестирования рекомендует- 
ся внимательно изучить 150В Glossary: 
http://www.istqb.org/downloads/glossary.html 


Для очень примерной оценки своего уровня владения английским языком можно 
воспользоваться представленными в широком ассортименте онлайн-тестами, на- 
пример вот этим: 

http://www.cambridgeenglish.org/test-your-english/ 


1.3.a{13} 


Пожалуйста, записывайте свои вопросы. Это не шутка. Сотнями исчисляются слу- 
чаи, когда на тренинге звучит что-то в стиле «Я ж такое (!!!) хотел(а) спросить и за- 


был(а) ©». 


2.1.229} 


Если есть ощущение, что многое непонятно или забылось, используйте как источник 
данные отсюда http://istqbexamcertification.com/what-are-the-software-development- 
models и попытайтесь сделать что-то наподобие собственного конспекта. 


2.2.а134 


Учли ЛИ ВЫ при составлении списка не только возможность ваших собственных не- 
доработок, но и объективные факторы риска? Например, цена на некоторый товар 
выросла, товара не оказалось в наличии. Продумали ЛИ ВЫ, КТО уполномочен прини- 
мать решение В ситуации, когда «посовещаться со всеми» невозможно или слишком 
долго? 


2.2.6453} 


При составлении списка вопросов рекомендуется опираться на две мысли: а) Как 
сделать продукт, максимально удовлетворяющий потребности заказчика. 6) Как реа- 
лизовать и протестировать то, что требует заказчик. 

Игнорирование любого из этих пунктов может привести либо к созданию бесполез- 
ного продукта, либо к работе в ситуации неопределённости, когда по-прежнему не 
до конца ясно, что же разрабатывать и как это тестировать. 


2.2.456} 


После того как вы выполнили это задание, проверьте себя с помощью материала гла- 
вы «Типичные ошибки при анализе и тестировании требований»{}. Если вы обна- 
ружили в своей работе какие-то из перечисленных там ошибок, исправьте их. 


2.2.4461} 


2.2.61} 


В продолжение теста на внимательность: заметили ли вы в тексте этой книги сколь- 
ко-нибудь опечаток? Поверьте, они здесь есть. 


По мере детализации набора требований ваши вопросы могут становиться всё более 
и более конкретными. Также помните, что стоит постоянно держать в голове всю 
общую картину требований, т.к. на низком уровне может проявиться проблема, за- 
трагивающая обширную часть требований и влияющая на весь проект. 


2.3.а{76} 


После того, как у вас закончатся собственные идеи, вы можете прибегнуть к неболь- 
шой хитрости: поищите в Интернете (и книгах, на которые приведено множество 
ссылок) описание различных видов тестирования, изучите области их применимо- 
сти и дополните свой список на основе полученных знаний. 
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[продолжение] 


Задание 


Комментарий 


2.4.2118} 


После того, как вы составите список свойств качественных требований, характерных 
для чек-листов, подумайте, какими свойствами должен обладать чек-лист, чтобы 
быть универсальным (т.е. чтобы его можно было использовать повторно на другом 
проекте). 


2.45121} 


На чём базировались ваши правки существующего чек-листа? Можете ли вы аргу- 
ментированно доказать преимущества предложенного вами варианта? 


2.4.с1137) 


Возможно, кто-то из ваших знакомых тестировщиков может рекомендовать вам то 
или иное инструментальное средство, исходя из собственного опыта. Если такого 
источника информации у вас нет, возьмите список соответствующего ПО из Вики- 
педии и/или многочисленных обзоров в Интернете. 


2.4.4014 


Насколько приоритетным будет данный тест-кейс? Если он обнаружит ошибку в 
приложении, какое значение важности вы ей присвоите? (Примечание: сама идея 
«повторной конвертации» бессмысленна, тк. повторная конвертация файла, ко- 
дировка которого была приведена к ОТЕЗ, ничем по сути не отличается от просто 
первичной конвертации файла, изначально находящегося в этой кодировке. Потому 
весь этот тест-кейс можно удалить, добавив в один из других тест-кейсов файл в ко- 
дировке UTF8 на вход конвертации.) 


2.4.е{155} 


Заметили ЛИ ВЫ ОТЛИЧИЯ В рекомендациях по написанию тест-кейсов и вообще по 
проведению тестирования В проектах, реализуемых по «классическим» и гибким ме- 
тодологиям? 


2.4.0157) 


Если вы хорошо знаете какой-то язык программирования, можете написать про- 
грамму, автоматизирующую представленные в данных командных файлах проверки. 


2.4.2160} 


Можно ли сделать ваши автоматизированные проверки более универсальными? 
Можно ли вынести за пределы командных файлов наборы данных? А логику обра- 
ботки данных? 


2.5.а{175} 


Ответ: в отчёте приведена ссылка на требование ДС-2.1, в котором сказано, что об- 
работанные файлы помещаются в каталог-приёмник, а не перемещаются туда. Ко- 
нечно, это дефект требований, но если подходить строго формально, то в требовани- 
ях нигде не сказано о перемещении обработанного файла, а потому отчёт о дефекте 
приложения может быть закрыт, хотя повторная обработка одного и того же фай- 
ла явно противоречит здравому смыслу. Однако! Может выясниться, что заказчик 
имел в виду, что приложение должно создавать в каталоге-приёмнике обработанные 
копии всех файлов из каталога-источника... и тут придётся многое переписывать, 
т.к. между «обработать и переместить все файлы» и «обработать и скопировать все 
новые файлы, не затрагивая повторно никакие ранее обработанные файлы» есть су- 
щественная разница (вплоть до того, что придётся вычислять и хранить контроль- 
ные суммы всех файлов, т.к. нет никакой гарантии, что в каталоге-приёмнике ка- 
кой-то файл не был заменён одноимённым). 


2.5.0191 


Возможно, кто-то из ваших знакомых тестировщиков может рекомендовать вам то 
или иное инструментальное средство, исходя из собственного опыта. Если такого 
источника информации у вас нет, возьмите список соответствующего ПО из Вики- 
педии и/или многочисленных обзоров в Интернете. 


2.6.а12181 


Для начала можно ознакомиться с этим примером: 
http://www.softwaretestingclass.com/wp-content/uploads/2013/01/Sample-Test-Plan- 
Template.pdf 
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[окончание] 


Задание 


Комментарий 


2.6.6225} 


Для начала можно ознакомиться с этим примером: 
https://www.assess.com/xcart/skin1/downloads/Sample_14_output.pdf 


2.6.c{231} 


2.7.а{234} 


Какие отвлекающие факторы снижали вашу производительность? Что у вас занима- 
ло больше всего времени (обдумывание тест-кейсов, оформление или что-то иное)? 
Как вы считаете, повысилась или понизилась бы ваша производительность, если бы 
вы провели за изучением требований к проекту несколько часов или даже дней? 


Ответ: потому, что здесь мы бы уже проверяли фактически взаимодействие двух па- 
раметров. Это хорошая идея, но она выходит за рамки тестирования отдельной изо- 
лированной функциональности. 


2.7.0238} 


Самым эффективным способом доработки представленного списка является... про- 
граммирование. Если вы достаточно хорошо знаете какой-нибудь язык программи- 
рования, напишите небольшую программу, которая всего лишь будет получать из 
командной строки имя каталога и проверять его наличие и доступность для чтения. 
А затем протестируйте вашу программу и дополните представленный в задаче спи- 
сок идеями, которые придут к вам в процессе тестирования. 


2.7.47} 


В колонке «Наличие прав доступа» иногда отсутствуют значения, т.к. если каталог 
отсутствует, к нему неприменимо понятие «права доступа». Что касается лишних 
проверок, то, например, в строках 18 и 22 пути приведены с «/» в качестве раздели- 
теля имён каталогов, что характерно для Linux, но не для Windows (хотя и сработает 
в большинстве случаев). Такие проверки можно оставлять, но можно и убирать как 
низкоприоритетные. 


2.7.4250} 


А если, кроме сложности, оценить также время на разработку тест-кейсов и прове- 
дение тестирования? А потом учесть необходимость повторять те же проверки мно- 
гократно? 


2.7.е{252} 


Можно использовать приведённый на рисунке 2.5.е169} пример описания дефекта 
как шаблон для решения этого задания. 


2.7.8255} 


Ответ: это плохое решение, т.к. теперь приложение будет пропускать имена катало- 
гов вида «/////C:/dir/name/». Конечно, при проверке существования такой каталог не 
будет найден, но фильтрация данных всё равно нарушена. А вот имя «/» всё равно 
превратится в пустую строку. 
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КОМАНДНЫЕ ФАЙЛЫ 

ДЛЯ WINDOWS И LINUX, 
АВТОМАТИЗИРУЮЩИЕ 
ВЫПОЛНЕНИЕ ДЫМОВОГО 
ТЕСТИРОВАНИЯ 


СМО-СКРИПТ ДЛЯ WINDOWS 


rem Переключение кодовой таблицы консоли 
rem (чтобы корректно обрабатывались спецсимволы в командах): 


сһср 65001 


rem Удаление файла журнала от прошлого запуска: 


del smoke _test.log /Q 


rem Очистка входного каталога приложения: 


del тм\*.* /Q 


rem Запуск приложения: 


start php converter.php ТМ OUT converter.log 


rem Размещение тестовых файлов во входном каталоге приложения: 


сору Test_IN\*.* IN > nul 


rem Таймаут в 10 секунд, чтобы приложение успело обработать файлы: 


timeout 10 


гет Остановка приложения: 


taskkill /IM php.exe 


rem Проверка появления в выходном каталоге файлов, 
rem которые должны быть обработаны, 
гет и непоявления файлов, которые не должны быть обработаны: 


echo Processing test: >> smoke_test.log 


IF EXIST "ООТ\«Мелкий» файл в WIN1251.txt" ( 


echo OK! '«Мелкий» файл в WIN1251.txt' file was processed! >> smoke_test.log 
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) ELSE ( 
echo ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\«Средний» файл в CP866.txt" ( 
echo OK! '«Средний» файл B CP866.txt' file was processed! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Средний» файл B CP866.txt' file was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\«Крупный» файл в KOI8R.txt" ( 
echo OK! '«Крупный» файл в KOI8R.txt' file was processed! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Крупный» файл в KOI8R.txt' file was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\«Крупный» файл в win-1251.html" ( 
echo ОК! '«Крупный» файл в win-1251.html' file was processed! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Крупный» файл в win-1251.html' file was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\«Мелкий» файл в cp-866.html" ( 
echo OK! '«Мелкий» файл в cp-866.html' file was processed! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Мелкий» файл B cp-866.html' file was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\«Средний» файл в koi8-r.html" ( 
echo OK! '«Средний» файл в koi8-r.html' file was processed! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Средний» файл в koi8-r.html' file was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\«Средний» файл в WIN_1251.md" ( 
echo ОК! '«Средний» файл в И1М 1251.ш4' file was processed! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Средний» файл в WIN_1251.md' file was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\«Крупный» файл в CP_866.md" ( 
echo OK! '«Крупный» файл в CP_866.md' file was processed! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Крупный» файл в CP_866.md' file was NOT processed! >> smoke_test.log 
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ТЕ EXIST "ООТ\«Мелкий» файл в KOI8_R.md" ( 
echo ОК! '«Мелкий» файл в КОІ8 В.ш' file was processed! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Мелкий» файл в КОТ8_В.ша' file was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\Слишком большой файл. хе" ( 
echo ERROR! 'Тоо big' file was processed! >> smoke_test.log 
) ELSE ( 


echo OK! 'Too big' file was NOT processed! >> smoke_test.log 


IF EXIST "О0Т\Картинка.јрд" ( 
echo ERROR! Picture file was processed! >> smoke_test.log 
) ELSE ( 


echo OK! Picture file was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\Картинка в виде TXT.txt" ( 
echo ОК! Picture file with TXT extension was processed! >> smoke_test.log 
) ELSE ( 


echo ERROR! Picture file with TXT extension was NOT processed! >> smoke_test.log 


IF EXIST "ООТ\Пустой файл.ша" ( 
echo ОК! Empty was processed! >> smoke_test.log 
) ELSE ( 


echo ERROR! Empty file was NOT processed! >> smoke_test.log 


rem Проверка удаления из входного каталога файлов, 

гет которые должны быть обработаны, 

гет и неудаления файлов, которые не должны быть обработаны: 
echo. >> smoke_test.log 


echo Moving test: >> smoke_test.log 


IF NOT EXIST "ІМ\«Мелкий» файл в WIN1251.txt" ( 
echo OK! '«Мелкий» файл в WIN1251.txt' file was moved! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT moved! >> smoke_test.log 
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ТЕ МОТ EXIST "ТМ\ «Средний» файл в CP866.txt" ( 
echo ОК! '«Средний» файл в CP866.txt' file was moved! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Средний» файл B CP866.txt' file was NOT moved! >> smoke_test.log 


ТЕ NOT EXIST "ІМ\«Крупный» файл в KOI8R.txt" ( 
echo OK! '«Крупный» файл в KOI8R.txt' file was moved! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Крупный» файл в KOI8R.txt' file was NOT moved! >> smoke_test.log 


ТЕ NOT EXIST "ТМ\«Крупный» файл в win-1251.html" ( 
echo OK! '«Крупный» файл в win-1251.html' file was moved! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Крупный» файл в win-1251.html' file was NOT moved! >> smoke_test.log 


ТЕ NOT EXIST "ІМ\«Мелкий» файл в cp-866.html" ( 
echo OK! '«Мелкий» файл в cp-866.html' file was moved! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Мелкий» файл в cp-866.html' file was NOT moved! >> smoke_test.log 


ТЕ NOT EXIST "ТМ\ «Средний» файл в koi8-r.html" ( 
echo ОК! '«Средний» файл в koi8-r.html' file was moved! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Средний» файл в koi8-r.html' file was NOT moved! >> smoke_test.log 


ТЕ NOT EXIST "ТМ\«Средний» файл в ИТМ 1251.та" ( 
echo ОК! '«Средний» файл в И1М 1251.ш4' file was moved! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Средний» файл в WIN_1251.md' file was NOT moved! >> smoke_test.log 


ТЕ NOT EXIST "ІМ\«Крупный» файл в СР_866.ша" ( 
echo ОК! '«Крупный» файл в СР 866.ш@' file was moved! >> smoke_test.log 
) ELSE ( 


echo ERROR! '«Крупный» файл в CP_866.md' file was NOT moved! >> smoke_test.log 


IF NOT EXIST "ІМ\«Мелкий» файл B KOI8_R.md" ( 


echo ОК! '«Мелкий» файл в КОІ8 R.md' file was moved! >> smoke_test.log 
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) ELSE ( 


echo ERROR! '«Мелкий» файл в КОТ8_В.ша' file was NOT moved! >> smoke_test.log 


ТЕ NOT EXIST "ІМ\Слишком большой файл.Ехе" ( 
echo ERROR! 'Тоо big' file was moved! >> smoke_test.log 
) ELSE ( 


echo OK! 'Too big' file was NOT moved! >> smoke_test.log 


IF NOT EXIST "ІМ\Картинка.јрд" ( 
echo ERROR! Picture file was moved! >> smoke_test.log 
) ELSE ( 


echo OK! Picture file was NOT moved! >> smoke_test.log 


IF NOT EXIST "ТМ\Картинка в виде TXT.txt" ( 
echo OK! Picture file with TXT extension was moved! >> smoke_test.log 
) ELSE ( 


echo ERROR! Picture file with TXT extension was NOT moved! >> smoke_test.log 


rem Проверка конвертации файлов путём сравнения 
rem результатов работы приложения с эталонными файлами: 
echo. >> smoke_test.log 


echo Comparing test: >> smoke_test.log 


:561 

Ес "Теѕі ЕТАГОМ\«Мелкий» эталон WIN1251.txt" "ООТ\«Мелкий» файл в WIN1251.txt" /В > nul 
ТЕ ERRORLEVEL 1 СОТО stl_fail 

echo ОК! File '«Мелкий» файл в WIN1251.txt' was processed correctly! >> smoke_test.log 
GOTO st2 

:stl_fail 


echo ERROR! File '«Мелкий» файл в WIN1251.txt' was NOT processed correctly! >> smoke_test.log 


:st2 
Ес "Теѕі ЕТАТОМ\«Средний» эталон CP866.txt" "ООТ\«Средний» файл в CP866.txt" /В > nul 
ТЕ ERRORLEVEL 1 СОТО st2_fail 
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echo ОК! File '«Средний» файл в CP866.txt' was processed correctly! >> smoke_test.log 
GOTO st3 
:st2_fail 


echo ERROR! File '«Средний» файл в CP866.txt' was NOT processed correctly! >> smoke_test.log 


:st3 

fc "Test ЕТАТОМ\«Крупный» эталон КОІВЕ.іхі" "ООТ\«Крупный» файл в KOI8R.txt" /B > nul 
IF ERRORLEVEL 1 GOTO st3_fail 

echo OK! File '«Крупный» файл в KOI8R.txt' was processed correctly! >> smoke_test.log 
GOTO st4 

:st3_fail 


echo ERROR! File '«Крупный» файл в KOI8R.txt' was NOT processed correctly! >> smoke_test.log 


:st4 

fc "Test ЕТАГОМ\«Крупный» эталон B win-1251.html" "ООТ\«Крупный» файл в win-1251.html" /B > nul 
IF ERRORLEVEL 1 GOTO st4_fail 

echo OK! File '«Крупный» файл в win-1251.html' was processed correctly! >> smoke_test.log 
GOTO st5 

:st4_fail 


echo ERROR! File '«Крупный» файл B win-1251.html' was NOT processed correctly! >> smoke_test.log 


:565 

Ес "Test ЕТАЬОМ\«Мелкий» эталон в cp-866.html" "ООТ\«Мелкий» файл в cp-866.html" /В > nul 
ТЕ ERRORLEVEL 1 СОТО $%5 Ғаі1 

echo ОК! File '«Мелкий» файл в cp-866.html' was processed correctly! >> smoke_test.log 
СОТО st6 

:st5_fail 


echo ERROR! File '«Мелкий» файл в cp-866.html' was NOT processed correctly! >> smoke_test.log 


: 566 

Ес "Test ЕТАІОМ\«Средний» эталон в koi8-r.html" "ОПТ\«Средний» файл в koi8-r.html" /В > nul 
ТЕ ERRORLEVEL 1 СОТО st6_fail 

echo ОК! File '«Средний» файл в koi8-r.html' was processed correctly! >> smoke_test.log 
GOTO st7 

:st6_fail 


echo ERROR! File '«Средний» файл в koi8-r.html' was NOT processed correctly! >> smoke_test.log 


:567 

Ес "Test ЕТАЬОМ\«Средний» эталон в ИТМ 1251.4" "ООТ\«Средний» файл в ИТМ 1251.4" /В > nul 
ТЕ ERRORLEVEL 1 СОТО st7_fail 

echo ОК! File '«Средний» файл в МІМ 1251.ш@' was processed correctly! >> smoke_test.log 


GOTO 58 
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:st7_fail 


echo ERROR! File '«Средний» файл в WIN_1251.md' was NOT processed correctly! >> smoke_test.log 


:st8 

fc "Test ЕТАТОМ\«Крупный» эталон в CP_866.md" "ООТ\«Крупный» файл в CP_866.md" /В > nul 
IF ERRORLEVEL 1 GOTO st8_fail 

echo OK! File '«Крупный» файл в CP_866.md' was processed correctly! >> smoke_test.log 
GOTO st9 

:st8_fail 


echo ERROR! File '«Крупный» файл в CP_866.md' was NOT processed correctly! >> smoke_test.log 


:59 

Ес "Теѕі ЕТАГОМ\«Мелкий» эталон в КОТ8 В.А" "ООТ\«Мелкий» файл в КОТ8 R.md" /В > nul 
ТЕ ERRORLEVEL 1 СОТО 5+9 Ғаі1 

echo ОК! File '«Мелкий» файл в КОІ8 R.md' was processed correctly! >> smoke_test.log 
GOTO st10 

:st9 fail 


echo ERROR! File '«Мелкий» файл в КОТ8 R.md' was NOT processed correctly! >> smoke_test.log 


:st10 

fc "Теѕі ЕТАТОМ\Пустой файл.та" "О0Т\Пустой файл.та" /B > nul 

ТЕ ERRORLEVEL 1 СОТО 5410 Ғаі1 

echo ОК! File 'Пустой файл.тша' was processed correctly! >> smoke_test.log 
GOTO end 

:st10_fail 


echo ERROR! File 'Пустой файл.ша' was NOT processed correctly! >> smoke_test.log 


:end 
echo WARNING! File 'Картинка в виде TXT.txt' has NO etalon decision, and it’s OK for this file 


to be corrupted. >> smoke_test.log 


BASH-CKPMIIT ДЛЯ LINUX 
#!/bin/bash 


# Удаление файла журнала от прошлого запуска: 


rm -f smoke_test.log 


# Очистка входного каталога приложения: 


rm -r -f IN/* 
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# Запуск приложения: 


php converter.php ТМ OUT converter.log & 


# Размещение тестовых файлов во входном каталоге приложения: 


ср Теѕі ТМ/* IN/ 


# Таймаут в 10 секунд, чтобы приложение успело обработать файлы: 


sleep 10 


# Остановка приложения: 


killall php 


# Проверка появления в выходном каталоге файлов, которые должны быть обработаны, 
# и непоявления файлов, которые не должны быть обработаны: 


echo "Processing test:" >> smoke_test.log 


if [ -f "О0Т/«Мелкий» файл в WIN1251.txt" ] 
then 
echo "ОК! '«Мелкий» файл в WIN1251.txt' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Средний» файл в CP866.txt" ] 
then 
echo "ОК! '«Средний» файл в CP866.txt' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Средний» файл в CP866.txt' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "О0Т/«Крупный» файл в KOI8R.txt" ] 
then 
echo "ОК! '«Крупный» файл в КОІ8К.іхі' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Крупный» файл в KOI8R.txt' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/ «Крупный» файл в win-1251.html" ] 
then 
echo "ОК! '«Крупный» файл в win-1251.html' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Крупный» файл в win-1251.html' file was NOT processed!" >> smoke_test.log 
fi 
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if [ -f "ООТ/«Мелкий» файл в cp-866.html" ] 
then 
echo "ОК! '«Мелкий» файл в cp-866.html' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Мелкий» файл в cp-866.html' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "О0Т/«Средний» файл в koi8-r.html" ] 
then 
echo "ОК! '«Средний» файл B koi8-r.html' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Средний» файл в koi8-r.html' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Средний» файл в WIN_1251.md" ] 
then 
echo "ОК! '«Средний» файл в WIN_1251.md' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Средний» файл в WIN_1251.md' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Крупный» файл в CP_866.md" ] 
then 
echo "ОК! '«Крупный» файл в CP_866.md' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Крупный» файл в CP_866.md' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "OUT/«Menknň» файл в KOI8_R.md" ] 
then 
echo "OK! '«Мелкий» файл в KOI8_R.md' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Мелкий» файл в KOI8_R.md' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/Слишком большой файл.їхї" ] 
then 

echo "ERROR! 'Too big' file was processed!" >> smoke_test.log 
else 

echo "OK! 'Too big' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/Картинка.)рд" ] 
then 


echo "ERROR! Picture file was processed!" >> smoke_test.log 
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е1зе 
есһо 


fi 


if [ -f 


then 
echo 


else 


echo "ERROR! Picture file with TXT extension was NOT processed!" >> smoke_test.log 


fi 


if [ -f 


then 
echo 
else 
echo 
fi 


"OK! Picture file was NOT processed!" >> smoke_test.log 


"ОПТ/Картинка в виде ТХТ. хе" ] 


"ОК! Picture file with TXT extension was processed!" >> smoke_test.log 


"ОйТ/Пустой файл.та" ] 


"OK! Empty file was processed!" >> smoke_test.log 


"ERROR! Empty file was NOT processed!" >> smoke_test.log 


# Проверка удаления из входного каталога файлов, которые должны быть обработаны, 


# и неудаления файлов, которые не должны быть обработаны: 


echo "" >> smoke_test.log 


echo "Moving test:" >> smoke_test.log 


if [1 
then 
echo 
else 
echo 
fi 


-f "IN/«Menknň» файл в WIN1251.txt" ] 


"OK! '«Мелкий» файл в WIN1251.txt' file was moved!" >> smoke_test.log 


"ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT moved!" >> smoke_test.log 


-f "ТМ/ «Средний» файл в CP866.txt" ] 


"ОК! '«Средний» файл в CP866.txt' file was moved!" >> smoke_test.log 


"ERROR! '«Средний» файл в CP866.txt' file was МОТ moved!" >> smoke_test.log 


-f "ТМ/ «Крупный» файл в KOI8R.txt" ] 


"ОК! '«Крупный» файл в KOI8R.txt' file was moved!" >> smoke_test.log 


"ERROR! '«Крупный» файл в KOI8R.txt' file was МОТ moved!" >> smoke_test.log 
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-f "ІМ/ «Крупный» файл в win-1251.html" ] 


"ОК! '«Крупный» файл в win-1251.html' file was moved!" >> smoke_test.log 


"ERROR! '«Крупный» файл в win-1251.html' file was МОТ moved!" >> smoke_test.log 


-f "ІМ/ «Мелкий» файл в cp-866.html" ] 


"ОК! '«Мелкий» файл в cp-866.html' file was moved!" >> smoke_test.log 


"ERROR! '«Мелкий» файл в cp-866.html' file was NOT moved!" >> smoke_test.log 


-f "ТМ/ «Средний» файл в koi8-r.html" ] 


"ОК! '«Средний» файл в koi8-r.html' file was moved!" >> smoke_test.log 


"ERROR! '«Средний» файл в koi8-r.html' file was МОТ moved!" >> smoke_test.log 


-f "ТМ/ «Средний» файл B ИТМ 1251.та" ] 


"ОК! '«Средний» файл в ИТМ 1251.ш4' file was moved!" >> smoke_test.log 


"ERROR! '«Средний» файл в МІМ 1251.ш4' file was МОТ moved!" >> smoke_test.log 


-f "ТМ/«Крупный» файл в СР 866.ша" ] 


"ОК! '«Крупный» файл в СР 866.ша' file was moved!" >> smoke_test.log 


"ERROR! '«Крупный» файл в СР 866.ша' file was МОТ moved!" >> smoke_test.log 


-f "ІМ/ «Мелкий» файл в КОІ8 R.md" ] 


"ОК! '«Мелкий» файл в KOI8_R.md' file was moved!" >> smoke_test.log 


"ERROR! '«Мелкий» файл в KOI8_R.md' file was МОТ moved!" >> smoke_test.log 


-f "ІМ/ Слишком большой файл. хе" ] 


"ERROR! 'Тоо big' file was moved!" >> smoke_test.log 
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echo "ОК! 'Тоо Ъ19' file was МОТ moved!" >> smoke_test.log 


if [ ! -f "ТМ/Картинка.)рд" ] 


echo "ERROR! Picture file was moved!" >> smoke_test.log 


echo "OK! Picture file was NOT moved!" >> smoke_test.log 


if [ ! -f "ІМ/Картинка в виде TXT.txt" ] 


echo "OK! Picture file with TXT extension was moved!" >> smoke_test.log 


echo "ERROR! Picture file with TXT extension was NOT moved!" >> smoke_test.log 


if [ ! -f С"ТМ/Пустой файл.та" ] 


echo "OK! Empty file was moved!" >> smoke_test.log 


echo "ERROR! Empty file was NOT moved!" >> smoke_test.log 


# Проверка конвертации файлов путём сравнения результатов 
# работы приложения с эталонными файлами: 
echo "" >> smoke_test.log 


echo "Comparing test:" >> smoke_test.log 


if cmp -s "Test ЕТАГОМ/«Мелкий» эталон WIN1251.txt" "О0Т/«Мелкий» файл в WIN1251.txt" 
then 

echo "ОК! File '«Мелкий» файл в WIN1251.txt' was processed correctly!" >> smoke_test.log 
else 

echo "ERROR! File '«Мелкий» файл в WIN1251.txt' was NOT processed correctly!" >> smoke_test.log 
fi 


if cmp -s "Test ЕТАГОМ/«Средний» эталон CP866.txt" "ООТ/«Средний» файл CP866.txt" 
then 


echo "OK! File '«Средний» файл CP866.txt' was processed correctly!" >> smoke_test.log 
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е1зе 
есһо 


fi 


if cmp 

then 
echo 

else 
echo 


fi 


if cmp 

then 
echo 

else 
echo 


fi 


if cmp 

then 
echo 

else 
echo 


fi 


if cmp 

then 
echo 

else 
echo 


fi 


if cmp 

then 
echo 

else 
echo 


fi 


if cmp 

then 
echo 

else 


echo 


fi 


"ERROR! File '«Средний» файл CP866.txt' was NOT processed correctly!" >> smoke_test.log 


-s "Test ЕТАІОМ/«Крупный» эталон KOIBR.txt" "ООТ/«Крупный» файл KOI8R.txt" 


"OK! File '«Крупный» файл KOI8R.txt' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Крупный» файл KOI8R.txt' was NOT processed correctly!" >> smoke_test.log 


-s "Test ЕТАТОМ/«Крупный» файл в win-1251.html" "ООТ/«Крупный» файл в win-1251.html" 


"ОК! File '«Крупный» файл в win-1251.html' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Крупный» файл в win-1251.html' was NOT processed correctly!" >> smoke_test.log 


-s "Test ЕТАТОМ/«Мелкий» эталон в cp-866.html" "OUT/«Menkuň» файл в cp-866.html" 


"OK! File '«Мелкий» файл в cp-866.html' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Мелкий» файл в cp-866.html' was NOT processed correctly!" >> smoke_test.log 


-s "Test ЕТАТОМ/«Средний» эталон в koi8-r.html" "ОПТ/«Средний» файл в koi8-r.html" 


"OK! File '«Средний» файл в koi8-r.html' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Средний» файл в koi8-r.html' was NOT processed correctly!" >> smoke_test.log 


-s "Test ЕТАТОМ/«Средний» эталон в WIN_1251.md" "ООТ/«Средний» файл в WIN_1251.md" 


"OK! File '«Средний» файл в WIN_1251.md' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Средний» файл в WIN_1251.md' was NOT processed correctly!" >> smoke_test.log 


-s "Test ЕТАБОМ/«Крупный» эталон в CP_866.md" "ООТ/«Крупный» файл в CP_866.md" 


"ОК! File '«Крупный» файл в СР 866.ш4' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Крупный» файл в СР 866.ш@' was МОТ processed correctly!" >> smoke_test.log 
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if cmp 

then 
echo 

else 
echo 


fi 


if cmp 

then 
echo 

else 
echo 


fi 


-s "Test ЕТАЬОМ/«Мелкий» эталон B KOI8_R.md" "OUT/«Menknň» файл в KOI8_R.md" 


"ОК! File '«Мелкий» файл в КОТ8_В.ш@' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Мелкий» файл в KOI8_R.md' was NOT processed correctly!" >> smoke_test.log 


-s "Test ЕТАБОМ/Пустой файл.та" "ООТ/Пустой файл.та" 


"ОК! File 'Пустой файл.ті' was processed correctly!" >> smoke_test.log 


"ERROR! File 'Пустой файл.ш@' was NOT processed correctly!" >> smoke_test.log 


echo "WARNING! File 'Картинка в виде TXT.txt' has NO etalon decision, апа it's OK for this 


file to be corrupted." >> smoke_test.log 


ПРИМЕР РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ 
(НА ОДНОМ ИЗ ПЕРВЫХ БИЛДОВ, СОДЕРЖАЩИХ МНОЖЕСТВО ДЕФЕКТОВ) 


Processing test: 


ОК! '«Мелкий» файл в WIN1251.txt' file was processed! 


ОК! '«Средний» файл в CP866.txt' file was processed! 


ОК! '«Крупный» файл в KOI8R.txt' file was processed! 


ОК! '«Крупный» файл в win-1251.html' file was processed! 


ОК! '«Мелкий» файл в cp-866.html' file was processed! 


ОК! '«Средний» файл в koi8-r.html' file was processed! 


OK! '«Средний» файл в WIN_1251.md' file was processed! 


ОК! '«Крупный» файл в CP_866.md' file was processed! 


OK! '«Мелкий» файл в KOI8_R.md' file was processed! 


OK! 'Too big' file was NOT processed! 


OK! Picture file was NOT processed! 


OK! Picture file with TXT extension was processed! 


Moving 
ERROR! 
ERROR! 
ERROR! 
ERROR! 
ERROR! 
ERROR! 


test: 

'«Мелкий» файл в WIN1251.txt' file was NOT moved! 
'«Средний» файл в CP866.txt' file was NOT moved! 
'«Крупный» файл в KOI8R.txt' file was NOT moved! 
'«Крупный» файл в win-1251.html' file was NOT moved! 
'«Мелкий» файл в cp-866.html' file was NOT moved! 
'«Средний» файл в koi8-r.html' file was NOT moved! 
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ERROR! '«Средний» файл B ИТМ 1251.ш@' file was МОТ moved! 
ERROR! '«Крупный» файл в СР 866.ш4' file was МОТ moved! 
ERROR! '«Мелкий» файл в КОТ8_В.ша' file was МОТ moved! 
ОК! 'Тоо big' file was МОТ moved! 

OK! Picture file was NOT moved! 


ERROR! Picture file with TXT extension was NOT moved! 


Comparing test: 

ERROR! File '«Мелкий» файл в WIN1251.txt' was NOT processed correctly! 
ERROR! File '«Средний» файл в CP866.txt' was NOT processed correctly! 
ERROR! File '«Крупный» файл в KOI8R.txt' was NOT processed correctly! 
ERROR! File '«Крупный» файл в win-1251.html' was NOT processed correctly! 
ERROR! File '«Мелкий» файл в cp-866.html' was NOT processed correctly! 
ERROR! File '«Средний» файл в koi8-r.html' was NOT processed correctly! 
ERROR! File '«Средний» файл в WIN_1251.md' was NOT processed correctly! 
ERROR! File '«Крупный» файл в CP_866.md' was NOT processed correctly! 
ERROR! File '«Мелкий» файл в KOI8_R.md' was NOT processed correctly! 

OK! File 'Пустой файл.ша' was processed correctly! 

WARNING! File 'Картинка в виде TXT.txt' has NO etalon decision, and it's OK for this file 


to be corrupted. 
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Расположение / длина / 
значение / буйгст- Komu- 
№ | комбинация символов / ущ Наличие прав доступа | Семейство ОС p, 
вование ровки 
зарезервированное 
или свободное 

1. [XA Да о amnya Мык UTS 
жимому 

2. |smb://host/dir Нет Linux 32 bit UTF16 

3. |./dir ла E Мал ОЕМ 
содержимому 

4. [257 ИЕ Да Только к каталогу Windows 64 bit | ОЕМ 

Windows] 

5, |smb://host/dir/ ma EE ЕР UTF8 
жимому 

6. | пи] о РЕР OEM 
содержимому 

7. |\\ Нет Linux 64 bit UTF16 

8. |/dir Ла a шкен» лс OEM 
содержимому 

9. |./dir/ Нет Linux 32 bit OEM 

10. | ./dir per | egib UTF8 
жимому 

11. | smb://host/dir Да Только к каталогу Linux 64 bit UTF8 

12. | \\host\dir\ а О ЕО dabit ОТЕ 
жимому 

13. | host:/dir Нет Windows 32 bit | UTF8 

14. | Лаі\ Нет Windows 64 bit | UTF8 

15. | [0 символов] Нет Windows 32 bit | UTF16 

о conoi tonb Her Linux 32 bit UTF16 

для Linux] 

17. | .\dir\ Нет Windows 32 bit | UTF16 

18. | «/пробелы и русский/» Да о ERO LOED Windows 32 bit | OEM 
жимому 

19. | smb://host/dir/ Да Только к каталогу Linux 32 bit OEM 

20. | nul Да Windows 32 bit | UTF8 

21. | «/пробелы и русский» Нет Linux 32 bit OEM 

22. | host:/dir/ Да Только к каталогу Windows 64 Би | UTF8 

23. |../аіг Нет Windows 64 bit | UTF16 
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[продолжение] 
Расположение / длина / 
значение / Сушест- Коди- 
№ | комбинация символов / ущ Наличие прав доступа | Семейство ОС д 
вование ровки 
зарезервированное 
или свободное 
24. | ./dir/ Нет Linux 64 bit UTF16 
A E Windows 32bit |UTF16 
Windows] 
26. | «/пробелы и русский/» Нет Linux 64 bit UTF8 
27. |.. Нет Windows 32 bit | UTF8 
28. | host:/dir/ Нет Linux 64 bit OEM 
29. | XAdir\ д | о малы шү OITS 
жимому 
30. |\\ jja, | шик ыы О 
содержимому 
31.|// Нет Только к каталогу Windows 64bit | ОТЕ8 
32. |.\dir\ нег |Никкаталогу ни ке dos Gabi |ОЕМ 
содержимому 
33. | X:\dir Нет Только к каталогу Windows 64 bit | ОЕМ 
34. | «Х\пробелы и русский\» Да Только к каталогу Windows 64 bit | ОТЕ16 
35. | \\host\dir\ Нет Только к каталогу Windows 32 bit | UTF16 
36. [256 СИМВОЛОВ ТОЛЬКО ДЛЯ Да К каталогу и его содер- Windows 32bit ПОТЕЗ 
Windows] жимому 
37. [е NOROS ки Нет Только к каталогу Linux 64 bit UTF16 
для Linux] 
38. | /dir/ И н ыы UTF8 
жимому 
39, [256 СИМВОЛОВ ТОЛЬКО для Да К каталогу и его содер- Windows 64bit |ОЕМ 
Windows] жимому 
40. | Adir Нез [ее онн че ОЕ 
жимому 
41. | // Да НИТ Windows 32 bit | ОЕМ 
содержимому 
42. | prn Да NEA, м O 
содержимому 
43. | .\dir нег | ККЕ данк чл елы ҮЙГӨ 
содержимому 
44. | \\host\dir\ Нет Только к каталогу Windows 64 bit | UTF16 
45. | ../dir/ вы ОТЕ 
содержимому 
46. |.. Да Только к каталогу Linux 32 bit OEM 
47. |.Лаіг Да Только к каталогу Windows 32 bit | ОТЕ8 
48. | /аіг Да Только к каталогу Linux 64 bit UTF8 
49. | « Нет | Только к каталогу Windows 32 bit | UTF8 
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[продолжение] 
Расположение / длина / 
значение / Сушест- Коли- 
№ | комбинация символов / а Наличие прав доступа | Семейство ОС а 
вование ровки 
зарезервированное 
или свободное 

50. |../dir/ Нег [| ХаТалогу и его содер- |ы |утв16 
жимому 

51. | Лат Да Только к каталогу Windows 64 bit | OEM 

52. |host:/dir/ Нег |-и Ккаталогу, E |утв16 
содержимому 

53. |«/пробелы и русский» Нет о Linux 64 bit UTF16 
жимому 

54. |com1-com9 да |Ник каталогу, никего Тл сы (UTIS 
содержимому 

55. |1рї1-1рї9 Да Только к каталогу Windows 32 bit |ОТЕ8 

56. | [0 символов] Нет Только к каталогу Linux 64 bit UTF16 

57. |\\host\dir да |Никкаталоту, ни donaa н (ОТЕІ6 
содержимому 

58. | «Х:\пробелы и русский» Да Только к каталогу Windows 64bit |UTF16 

59. | \\host\dir Her |Толькок каталогу Linux 64 bit UTF8 

60. |1рї1-1рї9 Да Только к каталогу Windows 64 bit | UTF8 

61. |«Х:\пробелы и русский» Нет ова шори ВО ндер» Windows 32 bit | OEM 
жимому 

62. | host:/dir да | каталогу и его содер- |, 32bit OEM 
жимому 

63. | X:\ Да Только к каталогу Windows 32 bit |ОЕМ 

64. | \\ Нет Только к каталогу Windows 32 bit |ОЕМ 

65. [4096 символов только Tia К каталогу и ero содер- Linux 32 bit UTE8 

для Linux] жимому 

66. | \\host\dir Her | Каталогу и ero содер- e| Windows64bit |ОЕМ 
жимому 

67. |« Нек | ИТОГИ НИ его зз н ОЕМ 
содержимому 

68. | соп Нет АТИ ВОДЕ Windows 32 bit | UTF16 
жимому 

69. | ../dir Her Только к каталогу Linux 32 bit UTF16 

70. |Х:\йг да [| аталогу и его содер хдо 32bit (OEM 
жимому 

71. |./dir да | каталогу и его содер- ор: |ОТЕб 
жимому 

72. 1/1 да; О АОВ м мл UTF16 
жимому 

73. | host:/dir Нет | eraan ни кего negabit рр 
содержимому 
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[окончание] 
Расположение / длина / 
значение / Grmec- Konu- 
№ | комбинация символов / уп Наличие прав доступа | Семейство ОС А 
вование ровки 
зарезервированное 
или свободное 

74. |] Ше | шерин РТ UTES 
жимому 

75. | «Х\пробелы и русский\» Да ОИ Windows 32 bit | ОЕМ 
содержимому 

76. | \dir\ о р о 
содержимому 

77+ | Нет Только к каталогу Linux 64 bit OEM 

78. | X:\dir\ Да Только к каталогу Windows 32 bit | UTF8 

79. | « ПИ UTF16 
содержимому 

80. | / да. СОТО ОРУ За ОТЕ16 
жимому 

81. Ла ИР ын е ые ота 
жимому 

82. | сот1-сот9 Да Ни к каталогу, ни к его Windows 32 bit | ОЕМ 
содержимому 

83. РРР" ОЕМ 
содержимому 

84. | /dir/ д ay ры UTF16 
жимому 

85. [4097 символов только klet К каталогу и его содер- Linux 64 bit UTF16 

для Linux] жимому 


4.5. СПИСОК ОСНОВНЫХ ОПРЕДЕЛЕНИЙ 
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45. СПИСОК ОСНОВНЫХ ОПРЕДЕЛЕНИЙ 


Для удобства поиска термины приведены в алфавитном порядке со ссылками на то место в 
книге, где находится их подробное рассмотрение. Здесь представлены только самые важные, са- 
мые ключевые определения из двух слишним сотен, что рассмотрены в книге. 


Термин Термин 
5 Определение 
(по-русски) (по-английски) 

Автоматизи- ГЕТА Набор техник, подходов и инструментальных средств, 
рованное testin позволяющий исключить человека из выполнения HEKO- 
тестирование! } 5 торых задач в процессе тестирования. 

Тестирование, которое выполняется внутри организа- 
Альфа- : ции-разработчика с возможным частичным привлече- 

{86} |Alpha testing И Й 

тестирование нием конечных пользователей. Может являться формой 

внутреннего приёмочного тестирования. 

Процесс исследования и классификации первопричин 
Анализ Root cause возникновения событий, негативно влияющих на безо- 
первопричин!?53} |апа|уз15 пасность, здоровье, окружающую среду, качество, Ha- 

дёжность и производственный процесс. 
Бета Тестирование, которое выполняется вне организации- 

86 Beta testing разработчика с активным привлечением конечных поль- 

тестирование} ; 

зователей/заказчиков. 

Border condition, 
Граничное boundar Значение, находящееся на границе классов эквивалент- 
условие 35} 2 ности. 
condition 


Дефект1\16б9} 


Defect, anomaly 


Отклонение фактического результата от ожиданий Ha- 
блюдателя, сформированных на основе требований, 
спецификаций, иной документации или опыта и здраво- 
го смысла. 


Динамическое 
тестирование!72} 


Дымовое 
тестирование!80) 


Dynamic testing 


Smoke test 


Тестирование с запуском кода на исполнение. 


Тестирование, которое направлено на проверку самой 
главной, самой важной, самой ключевой функциональ- 
ности, неработоспособность которой делает бессмыс- 
ленной саму идею использования приложения (или ино- 
го объекта, подвергаемого дымовому тестированию). 


Инспекция (аудит) 
кода 99} 


Code review, 
code inspection 


Семейство техник повышения качества кода за счёт того, 
что в процессе создания или совершенствования кода 
участвуют несколько человек. В отличие от техник ста- 
тического анализа кода (по потоку управления и потоку 
данных), аудит кода также улучшает такие его характе- 
ристики как понятность, поддерживаемость, соответ- 
ствие соглашениям об оформлении и т.д. Аудит кода вы- 
полняется в основном самими программистами. 


306 


Раздел 4: ПРИЛОЖЕНИЯ MENE 


[продолжение] 


Термин 
(по-русски) 


Термин 
(по-английски) 


Определение 


Интеграционное 
тестирование? 7} 


Integration 
testing 


Тестирование, которое направлено на проверку взаи- 
модействия между несколькими частями приложения 
(каждая из которых, в свою очередь, проверена отдельно 
на стадии модульного тестирования). 


Класс эквивалент- 
ностиї?35} 


Equivalence class 


Набор данных, обрабатываемый одинаковым образом и 
приводящий к одинаковому результату. 


Метод белого 


Метод тестирования, в рамках которого у тестировщика 
есть доступ к внутренней структуре и коду приложения, 


{73} White box testing И 
ящика а также есть достаточно знаний для понимания увиден- 
ного. 
Комбинация методов белого ящика и чёрного ящика, со- 
Метод серого А стоящая в том, что к части кода и архитектуры у тести- 
т Gray box testing Р урыу 
ящика ровщика доступ есть, а к части — нет. (См. пояснения по 
альтернативному определению здесь: 170.) 
Метод тестирования, в рамках которого у тестировщика 
А либо нет доступа к внутренней структуре и коду при- 
Метод чёрного | уп ҮТР РУ УР упр 
4073) Black Бох testing | ложения, либо недостаточно знаний для их понимания, 
ящик 
либо он сознательно не обращается к этим данным в 
процессе тестирования. 
Числовая характеристика показателя качества. Может 
Метрика? 1} Metric включать описание способов оценки и анализа резуль- 
тата. 
Структура, систематизирующая различные виды про- 
Soft ектной деятельности, их взаимодействие и последова- 
oftware | 
Модель Devel i тельность в процессе разработки ПО. Выбор той или 
еуортеп 7 
разработки ПО!20) Мей Г иной модели зависит от масштаба и сложности проекта, 
ode Й 
предметной области, доступных ресурсов и множества 
других факторов. 
| | Тестирование, направленное на проверку отдельных 
Модульное Unit testing, р кы роверку 
небольших частей приложения, которые (как правило) 
(компонентное) component 
{77} | можно исследовать изолированно от других подобных 
тестирование testing 


частей. 


тестирование(83) 


Negative testing 


Набор тест- Test case suite, Совокупность тест-кейсов, выбранных с некоторой 06- 

кейсов 148} test suite, test set | щей целью или по некоторому общему признаку. 
Тестирование, направленное на исследование работы 

Негативное приложения в ситуациях, когда с ним выполняются (не- 


корректные) операции и/или используются данные, по- 
тенциально приводящие к ошибкам. 


Нефункцио- 
нальное 
тестирование! 8} 


Non-functional 
testing 


Тестирование, направленное на проверку нефункцио- 
нальных особенностей приложения (корректность реа- 
лизации нефункциональных требований), таких как 
удобство использования, совместимость, производи- 
тельность, безопасность и т.д. 
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[продолжение] 


Термин 
(по-русски) 


Термин 


(по-английски) 


Определение 


Нефункцио- 
нальные 


Non-functional 


Требования, описывающие свойства системы (удобство 
использования, безопасность, надёжность, расширяе- 


{41} requirements мость и T. д.), которыми она должна обладать при реали- 
требования 
зации своего поведения. 
Отчёт Документ, описывающий и приоритизирующий обнару- 
Defect report y | риор РУ РУ 


о дефекте{171) 


Отчёт 
о результатах 
тестирования{218) 


Test progress 
report, 
test summary 
report 


женный дефект, а также содействующий его устранению. 


Документ, обобщающий результаты работ по тестирова- 
нию, и содержащий информацию, достаточную для со- 
отнесения текущей ситуации с тест-планом и принятия 
необходимых управленческих решений. 


Сбор и распространение информации о результатах ра- 


Отчётность {208} Reporting боты (включая текущий статус, оценку прогресса и про- 
гноз развития ситуации). 
Непрерывный процесс принятия управленческих реше- 
: ний и методической организации усилий по их реализа- 
Планирование!207! | Planning р y Р 


ции с целью обеспечения качества некоторого процесса 
на протяжении длительного периода времени. 


Позитивное 
тестирование!83) 


Positive testing 


Тестирование, направленное на исследование приложе- 
ния в ситуации, когда все действия выполняются строго 
по инструкции без каких бы то ни было ошибок, откло- 
нений, ввода неверных данных и т.д. 


Процентное выражение степени, в которой исследуе- 


Покрытие? 13} Coverage мый элемент затронут соответствующим набором TECT- 

кейсов. 

Формализованное тестирование, направленное на про- 
Приёмочное Acceptance верку приложения C точки зрения конечного пользовате- 
тестирование!89} ЧезНпе ля/заказчика и вынесения решения о том, принимает ли 

заказчик работу у исполнителя (проектной команды). 

Тестирование, направленное на исследование всей заяв- 
Расширенное Й 2 

182) | Extended test ленной в требованиях функциональности — даже той, 

тестирование 

которая низко проранжирована по степени важности. 

Тестирование, направленное на проверку того факта, что 
Регрессионное Кергеѕѕіоп в ранее работоспособной функциональности не появи- 
тестирование!89} | testing лись ошибки, вызванные изменениями в приложении 


или среде его функционирования. 


Тестирование, в котором тест-кейсы выполняются че- 


Ручное . 
y {75} Manual testing ловеком вручную без использования средств автомати- 
тестирование 
зации. 
Тестирование, направленное на проверку всего прило- 
Системное System testi жения как единого целого, собранного из частей, mpo- 
stem testin 
тестирование!78} / 8 веренных на стадиях модульного и интеграционного 


тестирования. 
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[продолжение] 
Термин Термин 
Е Определение 
(по-русски) (по-английски) 
Статическое . | 
{72} Static testing Тестирование без запуска кода на исполнение. 

тестирование 

Соруу нан Work breakdown Иерархическая декомпозиция объёмных задач на всё 60- 


декомпозиция!228) 


structure, WBS 


лее и более малые подзадачи с целью упрощения оценки, 
планирования и мониторинга выполнения работы. 


под управлением 
данными 5} 


Data-driven 
testing 


Тесті122) Test Набор из одного или нескольких тест-кейсов. 
Тестирование Тестирование, направленное на исследование функцио- 
критического Critical path test |нальности, используемой типичными пользователями B 
пути 81} типичной повседневной деятельности. 

еси ровови Способ разработки автоматизированных тест-кейсов, 


в котором входные данные и ожидаемые результаты 
выносятся за пределы тест-кейса и хранятся вне его — 
в файле, базе данных и т.д. 


Тестирование 
под управлением 
ключевыми 
словами} 


Keyword-driven 
testing 


Способ разработки автоматизированных тест-кейсов, 
в котором за пределы тест-кейса выносится не только 
набор входных данных и ожидаемых результатов, но и 
логика поведения тест-кейса, которая описывается клю- 
чевыми словами (командами). 


Тестирование 
под управлением 
поведением!95) 


Behavior driven 
testing 


Способ разработки автоматизированных тест-кейсов, 
в котором основное внимание уделяется корректности 
работы бизнес-сценариев, а не отдельным деталям функ- 
ционирования приложения. 


Тестирование Процесс анализа программного средства и сопутствую- 
программного Software testing | щей документации с целью выявления дефектов и повы- 
обеспечения! } шения качества продукта. 
Тестирование Исследование показателей скорости реакции приложе- 
Performance я $ 
производитель- : ния на внешние воздействия при различной по характе- 
ностиб93} каш ру и интенсивности нагрузке. 
Набор входных данных, условий выполнения и ожидае- 
мых результатов, разработанный с целью проверки того 
Тест-кейсй122) Ре или иного зона или поведения программного сред- 
ства. Под тест-кейсом также может пониматься соот- 
ветствующий документ, представляющий формальную 
запись тест-кейса. 
Документ, описывающий и регламентирующий перечень 
'Тест-планї?09%} Теве ріап работ по тестированию, а также соответствующие тех- 


ники и подходы, стратегию, области ответственности, 


ресурсы, расписание и ключевые даты. 


Описание того, какие функции и с соблюдением каких 


Требование!32) Requirement условий должно выполнять приложение в процессе pe- 
шения полезной для пользователя задачи. 
Количество рабочего времени, необходимого для выпол- 
Трудозатраты{?26} | Man-hours р р | а а 


нения работы (выражается в человеко-часах). 
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[окончание] 


Термин 
(по-русски) 


Термин 
(по-английски) 


Определение 


Функциональная 
декомпозиция!271) 


Functional 
decomposition 


Процесс определения функции через её разделение на 
несколько низкоуровневых подфункций. 


Функциональное 
тестирование!88} 


Functional testing 


Тестирование, направленное на проверку корректности 
работы функциональности приложения (корректность 
реализации функциональных требований). 


Требования, описывающие поведение системы, т.е. её 


Функциональные |Functional „ 
{41} : действия (вычисления, преобразования, проверки, об- 
требования requirements 
работку и т.д.). 
Набор идей [тест-кейсов]. Последнее слово не зря взято в 
| скобки, т. к. в общем случае чек-лист — это просто набо 
Чек-лист\117} Checklist | y P р 


идей: идей по тестированию, идей по разработке, идей 
по планированию и управлению — любых идей. 
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ЛИЦЕНЗИЯ 
“И РАСПРОСТРАНЕНИЕ 


РАЗДЕЛ 


< Данная книга распространяется под лицензией «Creative Commons 
(сс) O S Attribution-NonCommercial-ShareAlike 4.0 Тпїегпаййопа]»374, 


BY NC SA 


Текст книги периодически обновляется и дорабатывается. Если вы хотите поделиться этой 
книгой, пожалуйста, делитесь ссылкой на самую актуальную версию, доступную здесь: http:// 
svyatoslav.biz/software_testing_book/. 


Задать вопросы, сообщить о найденных ошибках или поделиться впечатлениями от прочитан- 
ного можно по адресу stb@svyatoslav.biz. 


ххх 


Если вам понравилась эта книга, обратите внимание на ещё одну, 
написанную в том же стиле: «Работа c MySQL, MS SQL Server и Oracle 
в примерах». 


Святослав Куликов: 


Работа с В книге: 3 СУБД, 50+ примеров, 130- задач, 500+ запросов с поясне- 
ШШ үш ниями и комментариями. Or SELECT * до поиска кратчайшего пути 
в ориентированном графе; никакой теории, только схемы и код, мно- 
го кода. Будет полезно тем, кто: когда-то изучал язык SQL, но многое 
забыл; имеет опыт работы с одним диалектом SQL, но хочет быстро 
переключиться на другой; хочет в предельно сжатые сроки научиться 


писать типичные 501-запросы. 


Скачать: http://svyatoslav.biz/database_book/ 
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